 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| user manual bcm1250/BCM1125/BCM1125h 1250_1125-um100-r 16215 alton parkway ? p.o. box 57013 irvine, ca 92619-7013 phone: 949-450-8700 fax: 949-450-8710 10/21/02 user manual for the bcm1250, BCM1125, and BCM1125h
r evision h istory revision date change description 1250-um100-r 06/25/01 initial release. 1250-um101-r 01/02/02 new sections: section : ?interrupts? on page 47 section : ?zbbus cycle count and compare? on page 58 . section : ?reduced cache size? on page 94 . section : ?cache configuration register? on page 99 . section : ?ddr fcrams? on page 123 . section : ?hypertransport read restrictions? on page 200 . section : ?hypertransport bounce space? on page 213 . section : ?hypertransport differences from revision 1.03 specification? on page 224 . section : ?hypertransport differences from revision 0.17 specification? on page 222 . section : ?hypertransport target done counter? on page 236 . section : ?tcp checksum checking? on page 282 . section : ?flow control in encoded packet fifo modes? on page 293 . section : ?restrictions when resetting the interface? on page 300 . section : ?burst mode? on page 370 . section : ?early chip select? on page 372 . section : ?transport protocol reset? on page 405 . section : ?extended protocol? on page 406 . section : ?bsrmode - holding boundary scan active? on page 434 . new tables: table 15 , table 48 , table 126 , table 127 , table 138 , table 139 , table 157 , table 203 , table 212 and table 214 . user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page iii 1250_1125- um100-r 10/21/02 this list summarizes the major changes between 1250-um101 and 1250_1125- um100. the 1250_1125-um100cb version of this manual has change bars indicating all changes between the older and newer versions. ? section 1: updates to describe BCM1125/h section 2: updates to describe BCM1125/h. section 3: additional clarifications and BCM1125/h descriptions new section: error conditions section 4: additional clarifications and BCM1125/h descriptions expanded section: bus watcher new section: magic decoder ring for using the trace buffer section 5: updates for BCM1125/h new register: level 2 cache settings register section 6: additional clarifications and BCM1125/h descriptions new section: memory access sequencing new section: example channel and chip select configurations updated guidelines: timing parameter guidelines section 7: additional clarifications and BCM1125/h descriptions new section: unaligned buffer descriptor format for ethernet dma new section: crc and checksum generators section 8: additional clarifications and BCM1125/h descriptions section 9: additional clarifications and BCM1125/h descriptions new section: prepended header frame format new functionality: destination address filtering new functionality: receive dma channel selection new functionality: flow control section 16: cross reference links added from register to defining table index: expanded revision date change description broadcom corporation p.o. box 57013 16215 alton parkway irvine, ca 92619-7013 ? 2002 by broadcom corporation all rights reserved printed in the u.s.a. broadcom ? and the pulse logo ? are trademarks of broadcom corporation and/or its subsidiaries in the united states and certain other countries. all other trademarks are the property of their respective owners. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page v t able of c ontents section 1: introduction ........................................................................................................ 1 the sibyte broadband processor family .................................................................................................. 1 the bcm1250 ............................................................................................................................... ................. 2 the BCM1125 and BCM1125h .................................................................................................................... 3 audience ............................................................................................................................... ........................ 3 other documentation ............................................................................................................................... ... 4 terminology ............................................................................................................................... ................... 5 section 2: signal overview ................................................................................................. 7 bcm1250 signal groups ............................................................................................................................. 7 BCM1125/h signal groups .......................................................................................................................... 8 section 3: system overview ............................................................................................... 9 introduction ............................................................................................................................... ................... 9 internal registers ............................................................................................................................... ........ 11 coherence ............................................................................................................................... .................... 12 ordering rules and device drivers .......................................................................................................... 14 cpu speculative execution ...................................................................................................................... 16 error conditions ............................................................................................................................... .......... 17 cache error exceptions ......................................................................................................... ............... 17 bus error exceptions ........................................................................................................... ................. 18 cpu to cpu communication (bcm1250 only) ........................................................................................ 19 external interrupts ............................................................................................................................... ...... 19 overview of the zbbus protocol ............................................................................................................... 20 arbitration.................................................................................................................... .......................... 21 address phase.................................................................................................................. .................... 22 response phase................................................................................................................. .................. 23 data phase ..................................................................................................................... ...................... 24 reset ............................................................................................................................... ............................ 26 clocks ............................................................................................................................... .......................... 31 memory map ............................................................................................................................... ................ 34 section 4: system control and debug unit ..................................................................... 41 introduction ............................................................................................................................... ................. 41 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page vi document 1250_1125-um100-r system control ............................................................................................................................... ............41 mailbox registers ............................................................................................................................... ........46 interrupts ............................................................................................................................... ......................47 hypertransport interrupts ...................................................................................................... ...............48 the full interrupt mapper ...................................................................................................... ................50 timers ............................................................................................................................... ...........................57 watchdog timers ................................................................................................................ ..................57 general timers................................................................................................................. .....................58 timer special cases ............................................................................................................ .................58 zbbus cycle count and compare.................................................................................................. .......58 timer registers ............................................................................................................... .....................59 system performance counters .................................................................................................................61 bus watcher ............................................................................................................................... .................64 address trapping ............................................................................................................................... ........67 trace unit ............................................................................................................................... .....................70 trigger events ................................................................................................................. ......................70 trigger sequences .............................................................................................................. ..................73 using the trace buffer......................................................................................................... ..................76 reading the trace buffer ....................................................................................................... ...............79 magic decoder ring for using the trace buffer .................................................................................8 1 connections to the trace logic................................................................................................. ............83 trace example 1: all cpu0 activity ............................................................................................. .........84 trace example 2: network packet headers........................................................................................ ..85 section 5: l2 cache .......................................................................................................... 89 introduction ............................................................................................................................... ..................89 normal operation ............................................................................................................................... ........89 using the l2 cache as memory .................................................................................................................91 standard ram ................................................................................................................... ....................92 memory locked in the l2 cache.................................................................................................. .........92 comments on using the l2 as memory ............................................................................................. ...93 reduced cache size............................................................................................................. ................94 cache management access ......................................................................................................................94 standard management mode accesses (both ecc_diag address bits zero) .......................................97 ecc diagnostic management accesses (ecc_diag bits nonzero) ......................................................98 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page vii cache configuration register ................................................................................................... ............ 99 example startup code to clear the l2 cache..................................................................................... .. 99 registers ............................................................................................................................... .................... 100 section 6: dram .............................................................................................................. 103 introduction ............................................................................................................................... ............... 103 a comment on the term bank..................................................................................................... ........ 103 memory controller architecture ............................................................................................................. 104 memory access sequencing ....................................................................................................... ....... 107 clock ratios and clocking scheme ....................................................................................................... 107 memory configurations ........................................................................................................................... 109 mapping ........................................................................................................................ ...................... 109 channel select................................................................................................................. ................... 109 chip select.................................................................................................................... ...................... 110 example channel and chip select configurations ............................................................................. 112 row, column and bank configuration............................................................................................. ... 117 choosing interleave parameters ................................................................................................. ....... 120 page policy .................................................................................................................... ..................... 122 supported drams and dimms...................................................................................................... ..... 123 ddr sdrams..................................................................................................................... ........ 123 ddr fcrams ..................................................................................................................... ........ 123 dimms .......................................................................................................................... ............... 124 larger memory systems .......................................................................................................... ........... 124 ecc ............................................................................................................................... ............................. 125 sdram timing ............................................................................................................................... .......... 125 sdram refresh ............................................................................................................................... ......... 126 sdram initialization and commands .................................................................................................... 126 i/o control ............................................................................................................................... .................. 128 timing parameter guidelines ................................................................................................................. 131 performance monitoring features .......................................................................................................... 134 zbbus monitoring ............................................................................................................................... ..... 134 configuration registers .......................................................................................................................... 135 section 7: dma .................................................................................................................147 dma controllers ............................................................................................................................... ........ 147 data buffers and descriptors ................................................................................................................. 147 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page viii document 1250_1125-um100-r unaligned buffer descriptor format for ethernet dma ........................................................................154 dma coherence and cache options ......................................................................................................155 dma configurations ............................................................................................................................... ..156 ethernet and serial dma engines ...........................................................................................................157 descriptor count watermarks .................................................................................................... .........157 completion interrupts .......................................................................................................... ................158 explicit descriptor interrupts................................................................................................. ...............158 asic mode transfers ............................................................................................................ ..............159 option and flag bits for ethernet macs ........................................................................................ ....171 control and flag bits for synchronous serial interface.......................................................................17 4 data mover ............................................................................................................................... .................176 data mover operation ........................................................................................................... ..............176 crc and checksum generators.................................................................................................... .....178 checksum generation............................................................................................................ ......178 crc generation................................................................................................................. ..........179 computation sizes and bandwidth ..............................................................................................18 0 examples....................................................................................................................... ...............181 data mover control registers ................................................................................................... ..........184 data mover descriptors......................................................................................................... ..............187 section 8: pci bus and hypertransport fabric ........................................................... 190 introduction ............................................................................................................................... ................190 pci and hypertransport address range ...............................................................................................192 memory mapped devices.......................................................................................................... ..........194 hypertransport expansion space................................................................................................. ......194 configuration space ............................................................................................................ ................194 pci i/o space.................................................................................................................. ....................195 the southbridge, vga and subtractive decode.................................................................................195 hypertransport end of interrupt (eoi) signaling space ....................................................................198 legacy interrupt acknowledge (iack) space .....................................................................................1 99 pci full access space .......................................................................................................... ..............199 special hypertransport space................................................................................................... .........199 hypertransport read restrictions ............................................................................................... .......200 endian policies ............................................................................................................................... ..........201 little endian system: no swaps ................................................................................................. ........201 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page ix big endian system: match byte lanes ............................................................................................ ... 202 big endian system: match bit lanes ............................................................................................. ..... 203 viewing endian policy as an optimization ....................................................................................... ... 204 accessing the sibyte from pci devices ................................................................................................ 205 accessing the sibyte from hypertransport devices ........................................................................... 210 force isochronous mode address range ................................................................................... 212 accessing the sibyte from a sibyte on a double hosted chain......................................................... 212 hypertransport bounce space.................................................................................................... ....... 213 performance of the pci and hypertransport interfaces ...................................................................... 213 accesses from the sibyte to the pci or hypertransport .................................................................... 214 accesses from the hypertransport to the sibyte ............................................................................... 21 6 accesses from the pci to the sibyte ............................................................................................ ...... 217 pci adaptive retry ............................................................................................................. ......... 217 peer-to-peer accesses ............................................................................................................................ 219 pci bus to hypertransport fabric............................................................................................... ...... 219 hypertransport fabric to pci bus ............................................................................................... ....... 221 pci arbiter ............................................................................................................................... ................. 222 pci interrupts ............................................................................................................................... ............ 222 hypertransport differences from revision 0.17 specification ........................................................... 222 hypertransport differences from revision 1.03 specification............................................................ 224 ordering rules................................................................................................................. ................... 231 using the pci in device mode ................................................................................................................. 232 configuration of pci and hypertransport ............................................................................................. 234 hypertransport target done counter ............................................................................................. ... 236 systems that do not use hypertransport......................................................................................... 236 configuration header descriptions .............................................................................................. ....... 236 pci configuration header ....................................................................................................... ............ 236 hypertransport configuration header ............................................................................................ .... 245 system reset initialization of the hypertransport interface ............................................................... 256 configuration flags in the sricmd register................................................................................. 257 timing registers: srirxden, sritxden, srirxnum and sritxnum ............................................. 257 receive pointer margin control in sricmd register.................................................................... 258 transmit pointer initial offset in the sricmd register ................................................................. 259 error control register ......................................................................................................... ......... 259 transmit control register ...................................................................................................... ...... 259 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page x document 1250_1125-um100-r buffer control: txbufcountmax and databufalloc.......................................................................260 hypertransport resets .......................................................................................................... .............260 section 9: ethernet macs .............................................................................................. 264 introduction ............................................................................................................................... ................264 interface overview ............................................................................................................................... ..... 265 protocol engine and gmii/mii ..................................................................................................................267 ethernet frame format .......................................................................................................... .............268 prepended header frame format .................................................................................................. ....270 protocol engine configuration.................................................................................................. ...........271 interface to phy ............................................................................................................... ...................271 transmitter operation ..............................................................................................................................2 72 transmitter configuration ...................................................................................................... ..............272 transmit path .................................................................................................................. ....................274 receiver operation ............................................................................................................................... ....275 receiver configuration ......................................................................................................... ...............275 receive path ................................................................................................................... ....................277 destination address filtering.................................................................................................. .............278 receive dma channel selection .................................................................................................. ......281 packet type identification ..................................................................................................... ..............282 ipv4 header checksum........................................................................................................... ............283 tcp checksum checking .......................................................................................................... .........283 packets dropped by the dma channel............................................................................................. ..283 flow control ............................................................................................................................... ...............284 interrupts ............................................................................................................................... ....................286 standard interrupt signaling................................................................................................... .............286 split interrupt signaling ...................................................................................................... .................286 management interface to phy .................................................................................................................287 rmon counters ............................................................................................................................... .........289 packet fifo interfaces .............................................................................................................................29 2 flow control in encoded packet fifo modes ....................................................................................29 4 8-bit packet fifo operation ....................................................................................................................294 8-bit gmii style packet fifo ................................................................................................... ...........295 8-bit encoded packet fifo...................................................................................................... ...........296 8-bit sop flagged packet fifo .................................................................................................. .......297 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xi 8-bit eop flagged packet fifo .................................................................................................. ....... 298 16-bit packet fifo operation ................................................................................................................. 299 16-bit gmii style packet fifo.................................................................................................. .......... 299 16-bit encoded packet fifo ..................................................................................................... ......... 300 restrictions when resetting the interface ............................................................................................ 301 mac registers ............................................................................................................................... ........... 302 section 10: serial interfaces ........................................................................................... 321 introduction ............................................................................................................................... ............... 321 asynchronous mode ............................................................................................................................... .322 baud rate generators ............................................................................................................................. 32 2 operation ............................................................................................................................... ................... 323 interrupts ............................................................................................................................... ................... 325 loopback ............................................................................................................................... ................... 326 duart registers ............................................................................................................................... ...... 327 synchronous mode ............................................................................................................................... ... 337 functional overview ............................................................................................................ ............... 337 input line interface ........................................................................................................... .................. 340 input using an external enable ................................................................................................. .. 340 input using the internal sequencer ............................................................................................. 341 output line interface .......................................................................................................... ................ 342 output using an external enable ................................................................................................ 342 output using the internal sequencer .......................................................................................... 34 3 synchronous serial protocol engine ..................................................................................................... 344 operation in hdlc mode......................................................................................................... ........... 344 framing parameters ............................................................................................................. ....... 345 hdlc transmitter ............................................................................................................... ......... 345 hdlc receiver .................................................................................................................. .......... 347 operation in transparent mode .................................................................................................. ........ 349 transmitter in transparent mode ................................................................................................ 350 receiver in transparent mode ................................................................................................... .350 synchronous interface configuration .................................................................................................... 351 dma configuration.............................................................................................................. ................ 351 fifo configuration ............................................................................................................. ................ 351 protocol engine configuration .................................................................................................. .......... 351 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xii document 1250_1125-um100-r line interface configuration ................................................................................................... .............352 synchronous serial interrupts ................................................................................................................352 synchronous serial loopback ................................................................................................................352 rmon counters ............................................................................................................................... .........353 synchronous serial register summary .................................................................................................354 section 11: generic/boot bus ........................................................................................ 362 introduction ............................................................................................................................... ................362 overview ............................................................................................................................... .....................362 configuring a chip select region ...........................................................................................................363 address range.................................................................................................................. ..................363 cacheable access blocking ...................................................................................................... ..........364 generic bus parity............................................................................................................. ..................364 bus width ...................................................................................................................... ......................365 generic bus timing ............................................................................................................. ................365 fixed cycle read access........................................................................................................ ............367 fixed cycle write access....................................................................................................... .............368 acknowledgement read access .................................................................................................... .....369 acknowledgement write access ................................................................................................... ......370 burst mode ..................................................................................................................... .....................371 early chip select .............................................................................................................. ...................373 boot rom support ............................................................................................................................... ....373 generic bus errors ............................................................................................................................... ....374 drive strength control .............................................................................................................................37 4 generic bus registers ............................................................................................................................375 section 12: pcmcia control interface .......................................................................... 384 introduction ............................................................................................................................... ................384 connecting a pcmcia slot ......................................................................................................................384 direct connection of a memory only card........................................................................................ ..385 other pcmcia signals........................................................................................................... .............389 using the pcmcia card ..........................................................................................................................390 example pcmcia timings ......................................................................................................... .........391 using the power outputs........................................................................................................ .............393 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xiii section 13: gpio .............................................................................................................. 397 introduction ............................................................................................................................... ............... 397 the gpio pins ............................................................................................................................... ........... 397 gpio registers ............................................................................................................................... .......... 399 other pins that can be used ................................................................................................................. 401 serial ports ................................................................................................................... ...................... 401 pci ............................................................................................................................ .......................... 401 macs ........................................................................................................................... ....................... 401 pcmcia power control pins ...................................................................................................... ........ 401 section 14: serial c onfiguration interface .................................................................... 404 introduction ............................................................................................................................... ............... 404 smbus overview ............................................................................................................................... ....... 404 transport protocol ............................................................................................................. ................. 404 transport protocol reset ....................................................................................................... ............. 406 smbus protocol ................................................................................................................. ................. 406 extended protocol.............................................................................................................. ................. 408 programming model ............................................................................................................................... .410 using smbus protocols .......................................................................................................... ............ 410 using extended protocols....................................................................................................... ............ 412 direct access ............................................................................................................................... ............ 413 booting using an smbus eeprom ........................................................................................................ 413 switching from smbus mode ...................................................................................................... ........ 414 smbus registers ............................................................................................................................... ....... 416 section 15: jtag and debug .......................................................................................... 422 introduction ............................................................................................................................... ............... 422 tap controller ............................................................................................................................... ........... 422 bypass instruction ............................................................................................................. ........ 425 idcode instruction ............................................................................................................. ........ 425 waferid instruction............................................................................................................ ....... 425 impcode instruction ............................................................................................................ ...... 426 address instruction ............................................................................................................ ...... 426 data instruction............................................................................................................... ........... 426 control instruction............................................................................................................ ...... 426 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xiv document 1250_1125-um100-r ejtagall instruction........................................................................................................... .......426 ejtagboot instruction .......................................................................................................... ....426 normalboot instruction ......................................................................................................... .427 scan instructions (0x26 - 0x38)................................................................................................ ..427 sysctrl instruction ............................................................................................................ .......427 trace instruction.............................................................................................................. ..........430 perf instruction ............................................................................................................... ...........430 tracectrl and tracecurcnt instructions .........................................................................431 processmon instruction......................................................................................................... .432 boundary scan register......................................................................................................... .............432 bsrmode - holding boundary scan active.......................................................................................43 5 processor and probe access ..................................................................................................................436 processor accesses to the jtag space........................................................................................... ..438 probe accesses to the zbbus .................................................................................................... .........438 address register ............................................................................................................... ..................439 data register.................................................................................................................. .....................439 ejtag control register ......................................................................................................... .............440 differences from ejtag 2.5 (feb. 22, 2000) specification ...................................................................442 section 16: reference ..................................................................................................... 446 internal register addresses by function ...............................................................................................446 bcm1250/BCM1125/h internal registers ordered by address ............................................................464 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xv l ist of f igures figure 1: bcm1250 block diagram ................................................................................................ .................... 2 figure 2: BCM1125/h block diagram .............................................................................................. .................. 3 figure 3: bcm1250 signals...................................................................................................... .......................... 7 figure 4: BCM1125/h signals .................................................................................................... ........................ 8 figure 5: logical block diagram of bcm1250 and BCM1125/h ....................................................................... .9 figure 6: internal control and status register alignment ....................................................................... ......... 11 figure 7: decision tree for memory space address accesses ...................................................................... .26 figure 8: clock distribution overview .......................................................................................... .................... 33 figure 9: memory map ........................................................................................................... .......................... 35 figure 10: per-cpu interrupt mapper (replicated for each cpu; x = 0 or 1).................................................... 51 figure 11: connections to trace logic.......................................................................................... ................... 83 figure 12: level 2 cache way disable access address ............................................................................ ..... 91 figure 13: cache management address............................................................................................ .............. 95 figure 14: memory controller block diagram ..................................................................................... ........... 105 figure 15: chip select options................................................................................................. ...................... 110 figure 16: example single channel 128mb........................................................................................ ........... 112 figure 17: example 1gb with two chip selects on one channel.................................................................... .113 figure 18: example 1gb with two chip selects interleaved on one channel .................................................. 114 figure 19: example 1gb with two chip selects interleaved across both channels ......................................... 115 figure 20: example 2gb with two chip selects interleaved on one channel .................................................. 116 figure 21: timing relationships set by dlls .................................................................................... ............ 130 figure 22: nominal windows at 133mhz for first edge of dqs for various settings of [tcrd, tcrdh, tfifo] .... 131 figure 23: dma buffer.......................................................................................................... .......................... 148 figure 24: dma descriptor ...................................................................................................... ....................... 149 figure 25: packet spanning three buffers ....................................................................................... ............. 150 figure 26: dma descriptor ring................................................................................................. .................... 151 figure 27: dma descriptor chain................................................................................................ ................... 153 figure 28: standard and unaligned buffer dma descriptors ....................................................................... .. 154 figure 29: packet reception flow using dma asic mode........................................................................... .159 figure 30: asic mode address generation ........................................................................................ ........... 160 figure 31: sending the whole packet in asic mode............................................................................... ...... 161 figure 32: sending a packet header in asic mode ................................................................................ ...... 162 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xvi document 1250_1125-um100-r figure 33: example 1 - tcp checksum a packet................................................................................... .........181 figure 34: example 2 - preparing an iscsi packet ............................................................................... .........182 figure 35: example 3 - fragmenting an iscsi packet............................................................................. .......183 figure 36: pci and hypertransport organization ................................................................................. .........191 figure 37: address ranges for cpu access to pci and hypertransport ......................................................193 figure 38: little endian system ................................................................................................ ......................201 figure 39: match byte lane endian policy ....................................................................................... ..............202 figure 40: match bit lane endian policy ........................................................................................ ................203 figure 41: pci bar0 address mapping table ...................................................................................... .........206 figure 42: default host mode memory map from pci bus master.................................................................209 figure 43: memory map from hypertransport device............................................................................... ....210 figure 44: buffers used for accesses from the zbbus to pci and hypertransport .......................................214 figure 45: buffers used for dma accesses from the pci and hypertransport .............................................216 figure 46: pci adaptive retry parameters....................................................................................... ..............218 figure 47: buffers used for pci to hypertransport peer-to-peer accesses ..................................................220 figure 48: buffers used for hypertransport to pci peer-to-peer accesses ..................................................221 figure 49: configuration space address ......................................................................................... ...............234 figure 50: hypertransport interface clocks and fifos ........................................................................... ......256 figure 51: ethernet interface block diagram .................................................................................... ..............265 figure 52: ethernet frame format ............................................................................................... ..................268 figure 53: prepended header format ............................................................................................. ...............270 figure 54: transmit fifo thresholds ............................................................................................ .................272 figure 55: receive fifo thresholds ............................................................................................. .................275 figure 56: receive address filter.............................................................................................. .....................278 figure 57: receive channel selection........................................................................................... .................281 figure 58: selecting the channel offset ........................................................................................ .................281 figure 59: mdio flows .......................................................................................................... .........................288 figure 60: 8-bit packet fifo gmii style ........................................................................................ .................295 figure 61: 8-bit packet fifo encoded style ..................................................................................... .............296 figure 62: 8-bit packet fifo sop style ........................................................................................ ................297 figure 63: 8-bit packet fifo eop style ........................................................................................ ................298 figure 64: 16-bit gmii style packet fifo ....................................................................................... ...............299 figure 65: 16-bit encoded packet fifo ......................................................................................... ...............300 figure 66: uart interrupt generation ........................................................................................... .................325 figure 67: synchronous interface block diagram ................................................................................. .........338 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xvii figure 68: example reception using rin as active high enable (sampling on the falling clock edge) ........ 340 figure 69: example reception using rin as active high sync (sampling on the falling clock edge) ........... 342 figure 70: example transmission using tin as active high enable (driving/sampling on rising clock edge) . 343 figure 71: example transmission using tin as active high sync (transition/sampling on rising clock edge) .... 344 figure 72: frame address matching .............................................................................................. ................ 347 figure 73: synchronous serial loopback connections............................................................................. ..... 352 figure 74: fixed cycle read access ............................................................................................. ................ 367 figure 75: fixed cycle write access............................................................................................ .................. 368 figure 76: acknowledge read access............................................................................................. .............. 369 figure 77: acknowledge write access ............................................................................................ ............... 370 figure 78: generic bus burst read.............................................................................................. .................. 371 figure 79: generic bus burst write............................................................................................. ................... 371 figure 80: example pcmcia slot connection ...................................................................................... ......... 385 figure 81: example flash card timing diagram ................................................................................... ........ 392 figure 82: single gpio pin diagram............................................................................................. ................. 397 figure 83: smbus signaling start, data transfer and stop ....................................................................... .... 405 figure 84: jtag tap state machine .............................................................................................. ............... 423 figure 85: jtag boundary scan register block ................................................................................... ........ 433 figure 86: jtag hypertransport output boundary scan block .................................................................... 43 4 figure 87: jtag hypertransport input boundary scan block....................................................................... 435 figure 88: example jtag probe flowchart ........................................................................................ ........... 437 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xviii document 1250_1125-um100-r user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xix l ist of t ables table 1: zbbus agent ids ...................................................................................................... ......................... 20 table 2: zbbus signals ........................................................................................................ ........................... 20 table 3: zbbus commands....................................................................................................... ...................... 22 table 4: zbbus level 1 cache attributes ....................................................................................... ................. 23 table 5: zbbus byte lane assignments .......................................................................................... ............... 24 table 6: zbbus data status codes .............................................................................................. .................. 24 table 7: operation of different reset sources................................................................................. ............... 27 table 8: static configuration options......................................................................................... ..................... 27 table 9: core and hypertransport clock settings............................................................................... ........... 31 table 10: overview of bcm1250 physical address map ............................................................................ .... 34 table 11: address map details ................................................................................................. ...................... 36 table 12: system identification and revision register ......................................................................... .......... 42 table 13: part revisions ...................................................................................................... ........................... 42 table 14: manufacturing information register .................................................................................. .............. 43 table 15: system configuration register....................................................................................... ................. 43 table 16: scratch register .................................................................................................... .......................... 45 table 17: mailbox registers ................................................................................................... ......................... 46 table 18: interrupt mappings.................................................................................................. ......................... 47 table 19: interrupt message format for writes to interrupt_ldt_set register.................................................. 4 9 table 20: delivery of hypertransport interrupts ............................................................................... .............. 49 table 21: interrupt registers ................................................................................................. .......................... 52 table 22: interrupt sources ................................................................................................... .......................... 52 table 23: watchdog timer initial count registers .............................................................................. ............ 59 table 24: watchdog timer current count registers .............................................................................. ........ 59 table 25: watchdog timer configuration registers.............................................................................. .......... 59 table 26: general timer initial count registers ............................................................................... .............. 60 table 27: general timer current count registers............................................................................... ........... 60 table 28: general timer configuration registers ............................................................................... ............ 60 table 29: zbbus count register ................................................................................................ ..................... 61 table 30: zbbus count compare registers....................................................................................... ............. 61 table 31: system performance counter configuration registers.................................................................. .61 table 32: system performance counters ......................................................................................... .............. 62 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xx document 1250_1125-um100-r table 33: system performance counter sources .................................................................................. .........62 table 34: bus watcher counters ................................................................................................ .....................64 table 35: bus watcher error status register ................................................................................... ...............65 table 36: bus watcher error status debug register ............................................................................. .........65 table 37: bus watcher error data registers.................................................................................... ...............65 table 38: bus watcher l2 ecc counter register................................................................................. ..........66 table 39: bus watcher memory and i/o error counter register................................................................... ..66 table 40: address trap trigger index register ................................................................................. ..............68 table 41: address trap trigger debug register ................................................................................. ............68 table 42: address trap trigger address register ............................................................................... ...........68 table 43: address trap range top address registers ............................................................................ ......68 table 44: address trap range base address registers ........................................................................... .....69 table 45: address trap configuration registers ................................................................................ .............69 table 46: trace event register ................................................................................................ .......................72 table 47: trace sequence control registers .................................................................................... ..............74 table 48: trace control register .............................................................................................. .......................76 table 49: trace buffer address/control bundle ................................................................................. .............77 table 50: trace entry format and read order ................................................................................... ............79 table 51: decode of some tids for system revision periph_rev3..............................................................81 table 52: encoded byte enables for cpu transactions ........................................................................... ......82 table 53: addresses for memory banks .......................................................................................... ................92 table 54: management address .................................................................................................. ....................95 table 55: ecc diagnostic operations ........................................................................................... ..................98 table 56: level 2 cache tag register .......................................................................................... ................100 table 57: level 2 cache settings register..................................................................................... ...............100 table 58: clock speed......................................................................................................... ..........................107 table 59: percent deltas from popular dimm frequencies........................................................................ ...108 table 60: mapping physical address to memory controller address...........................................................109 table 61: address bits used by a memory channel ............................................................................... ......117 table 62: example for 128 mbyte cs region with 4k rows, 1k columns ...................................................118 table 63: example for 128 mbyte cs region with 4k rows, 1k columns, 64 byte interleave ....................118 table 64: example for 128 mbyte cs region with 4k rows, 1k columns, 128 byte interleave ..................119 table 65: example for 256 mbyte region with 4k rows, 1k columns, two cs, and 128 byte interleave ...119 table 66: example for 512 mbyte region with 4k rows, 1k columns, four cs, and 128 byte interleave...119 table 67: example for 128 mbyte + 64 mb + 64 mb mixed_cs mode .........................................................120 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xxi table 68: supported sdrams .................................................................................................... .................. 123 table 69: commands that can be issued through mc_dramcmd register .................................................. 126 table 70: adjustment percentages and multiplier for values of dll m ........................................................ 128 table 71: first dqs window opening and closing (typical)...................................................................... .. 132 table 72: memory channel configuration register on bcm1250 ................................................................ 135 table 73: memory channel configuration register on BCM1125/h............................................................. 136 table 74: memory clock configuration register ................................................................................. .......... 138 table 75: dram command register ............................................................................................... ............. 139 table 76: dram mode register.................................................................................................. .................. 139 table 77: sdram timing register ............................................................................................... ................ 140 table 78: sdram timing register 2 ............................................................................................. ............... 141 table 79: chip select start address register .................................................................................. ............. 141 table 80: chip select end address register .................................................................................... ............ 141 table 81: chip select interleave register ..................................................................................... ................ 142 table 82: row address bits select register.................................................................................... ............. 142 table 83: column address bits select register................................................................................. ........... 142 table 84: bank address bits select register................................................................................... ............. 143 table 85: chip select attribute register ...................................................................................... ................. 143 table 86: ecc test data register .............................................................................................. .................. 144 table 87: ecc test ecc register ............................................................................................... ................. 144 table 88: data buffer parameters.............................................................................................. ................... 148 table 89: data parameters ..................................................................................................... ...................... 148 table 90: address used for asic mode transfers ................................................................................ ....... 160 table 91: ethernet and serial dma configuration register 0 .................................................................... ... 163 table 92: ethernet and serial dma configuration register 1 .................................................................... ... 164 table 93: ethernet and serial dma descriptor base address register........................................................ 166 table 94: asic mode base address.............................................................................................. ............... 166 table 95: descriptor count register ........................................................................................... .................. 166 table 96: current descriptor a debug register ................................................................................. ........... 167 table 97: current descriptor b debug register ................................................................................. ........... 167 table 98: current descriptor address register................................................................................. ............ 167 table 99: ethernet receive packet drop registers (only if system revision >= periph_rev3).............. 168 table 100: dma descriptor first doubleword .................................................................................... ........... 169 table 101: dma descriptor second doubleword................................................................................... ....... 169 table 102: unaligned buffer format dma descriptor first doubleword....................................................... 170 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xxii document 1250_1125-um100-r table 103: unaligned buffer format dma descriptor second doubleword ..................................................170 table 104: status flags for ethernet receive channel .......................................................................... .......171 table 105: option flags for ethernet receive channel .......................................................................... ......172 table 106: status flags for ethernet transmit channel ......................................................................... .......172 table 107: option flags for ethernet transmit channel ......................................................................... ......173 table 108: status flags for synchronous serial receive channel ...............................................................1 74 table 109: option flags for synchronous serial receive channel ...............................................................1 74 table 110: status flags for synchronous serial transmit channel ..............................................................1 74 table 111: option flags for synchronous serial transmit channel ..............................................................1 74 table 112: result in memory of appending the result crc[31:0]................................................................. .179 table 113: example crc configurations ......................................................................................... ..............180 table 114: data mover descriptor base address register ........................................................................ ...184 table 115: debug data mover descriptor base address register................................................................18 4 table 116: data mover descriptor count register ............................................................................... .........185 table 117: data mover current descriptor address .............................................................................. ........185 table 118: data mover crc definition registers (only if system revision >= periph_rev3) .................185 table 119: data mover crc/checksum definition registers (only if system revision >= periph_rev3)186 table 120: data mover channel partial result registers (only if system revision >= periph_rev3) .....186 table 121: data mover descriptor first doubleword ............................................................................. ........187 table 122: data mover descriptor second doubleword............................................................................ ....188 table 123: pci base address register use ...................................................................................... ............205 table 124: adaptive retry delay ............................................................................................... ....................218 table 125: error routing registers ............................................................................................ ...................229 table 126: pci csr access rules............................................................................................... .................233 table 127: pci interface configuration header (type 0) ........................................................................ ......236 table 128: pci command register - offset 4 bits [15:0] ........................................................................ ......240 table 129: pci status register - offset 4 bits [31:16]........................................................................ ...........240 table 130: pci latency timer - offset 0c bits [15:8] .......................................................................... ..........241 table 131: pci cache line size - offset 0c bits [7:0] ......................................................................... .........241 table 132: pci timeout register - offset 40 bits [15:0] ....................................................................... .........241 table 133: pci feature control register - offset 40 bits [31:16] .............................................................. ....242 table 134: pci bar0 map table entry - offset 44 ? 80 .......................................................................... .....242 table 135: pci additional status and control register - offset 88 bits [31:0] ..............................................242 table 136: pci inta control register - offset 90 bits [31:0] .................................................................. ......243 table 137: pci read host register - offset 94 bits [31:0] ..................................................................... .......243 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xxiii table 138: pci adaptive extend register - offset 98 bits [31:0] ............................................................... ... 243 table 139: pci bypass control register - revid >= 3 offset a8 bits [31:0] ................................................. 244 table 140: hypertransport configuration header (type 1) ....................................................................... ... 245 table 141: hypertransport bridge command register - offset 4 bits [15:0] ............................................... 247 table 142: hypertransport bridge primary (zbbus) status register - offset 4 bits [31:16]......................... 248 table 143: hypertransport bridge secondary (ht) status register - offset 1c bits [31:16]....................... 248 table 144: hypertransport bridge control register - offset 3c bits [31:16] ................................................ 249 table 145: hypertransport command register - offset 40 bits [31:16]....................................................... 249 table 146: hypertransport link control register - offset 44 bits [15:0] ...................................................... 2 50 table 147: hypertransport link configuration register - offset 44 bits [31:16] .......................................... 251 table 148: hypertransport link frequency register - offset 48 bits [15:8]................................................. 251 table 149: hypertransport sri command register - offset 50 bits [31:16] ................................................ 252 table 150: hypertransport isochronous bar - offset 5c bits [31:0] ........................................................... 25 2 table 151: hypertransport isochronous ignore mask - offset 60bits [31:0] ................................................ 253 table 152: hypertransport error control register - offset 68 bits [23:0]..................................................... 2 53 table 153: hypertransport error status register - offset 68 bits [31:24] .................................................... 25 4 table 154: hypertransport sri transmit control register - offset 6c bits [23:16] ..................................... 254 table 155: hypertransport sri data buffer allocation register - offset 6c bits [15:0] ............................... 254 table 156: hypertransport additional status register - offset 70 .............................................................. .255 table 157: hypertransport sri transmit buffer count max register - offset c8 bits [31:0]....................... 255 table 158: hypertransport diagnostic receive crc expected - offset dc ................................................ 255 table 159: hypertransport diagnostic receive crc received - offset f0 ................................................. 255 table 160: ethernet frame fields .............................................................................................. ................... 269 table 161: transmission error conditions ...................................................................................... .............. 273 table 162: receiver error conditions .......................................................................................... ................. 276 table 163: ethernet type mappings ............................................................................................. ................ 282 table 164: back pressure methods in half-duplex operation ..................................................................... .284 table 165: pause frame options................................................................................................ .................. 285 table 166: mac to phy management protocol ..................................................................................... ....... 289 table 167: rmon counters ...................................................................................................... .................... 289 table 168: BCM1125 ethernet/fifo pin usage .................................................................................... ......... 292 table 169: bcm1250 ethernet/fifo pin usage .................................................................................... ......... 293 table 170: codes for gmii packet fifo mode .................................................................................... ......... 295 table 171: codes for 8-bit encoded bypass mode................................................................................ ....... 296 table 172: codes for 8-bit sop packet fifo.................................................................................... ........... 297 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xxiv document 1250_1125-um100-r table 173: codes for 8-bit eop bypass mode.................................................................................... ..........298 table 174: codes for 16-bit gmii style packet fifo ............................................................................ ........300 table 175: codes for 16-bit encoded bypass mode ............................................................................... ......300 table 176: mac configuration registers ........................................................................................ ..............302 table 177: mac enable registers............................................................................................... ..................306 table 178: mac transmit dma control register .................................................................................. ........306 table 179: mac fifo threshold registers....................................................................................... ............307 table 180: mac frame configuration registers .................................................................................. .........308 table 181: mac vlan tag registers ............................................................................................. ..............310 table 182: mac status registers............................................................................................... ...................310 table 183: mac status 1 register .............................................................................................. ..................313 table 184: mac debug status registers ......................................................................................... .............313 table 185: mac interrupt mask registers ....................................................................................... ..............314 table 186: mac fifo pointer registers ......................................................................................... ..............314 table 187: mac receive address filter exact match registers ................................................................... 314 table 188: mac receive address filter mask registers (only if system revision >= periph_rev3)......315 table 189: mac receive address filter hash match registers.................................................................... 315 table 190: mac transmit source address registers .............................................................................. .....315 table 191: mac packet type configuration registers ............................................................................ .....316 table 192: mac receive address filter control registers ....................................................................... ....316 table 193: mac receive channel select map registers........................................................................... ...318 table 194: mac mii management interface registers ............................................................................. .....318 table 195: serial interface signal names ...................................................................................... ...............321 table 196: baud rate counter values ........................................................................................... ...............322 table 197: duart mode registers ............................................................................................... ...............327 table 198: duart second mode registers ........................................................................................ .........327 table 199: duart command registers ............................................................................................ ...........328 table 200: duart status registers ............................................................................................. ................328 table 201: duart baud rate clock registers .................................................................................... ........329 table 202: duart full interrupt control registers............................................................................. ..........329 table 203: duart received data registers ...................................................................................... ..........329 table 204: duart transmit data registers ...................................................................................... ...........330 table 205: duart input port register.......................................................................................... ................330 table 206: duart input port change status register ............................................................................ .....330 table 207: duart debug access input port change register ....................................................................33 1 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xxv table 208: duart input port change status register for channel a ......................................................... 331 table 209: duart input port change status register for channel b ......................................................... 331 table 210: duart output port control register................................................................................. ......... 331 table 211: duart per channel output control registers......................................................................... .. 332 table 212: duart aux control register ......................................................................................... ............. 332 table 213: duart per channel aux control registers ............................................................................ ... 332 table 214: duart interrupt status register .................................................................................... ............ 333 table 215: duart channel a only interrupt status register ..................................................................... .333 table 216: duart channel b only interrupt status register ..................................................................... .333 table 217: duart interrupt mask register ...................................................................................... ............ 334 table 218: duart channel a only interrupt mask register....................................................................... .334 table 219: duart channel b only interrupt mask register....................................................................... .334 table 220: duart output port set register ..................................................................................... ........... 335 table 221: duart output port clear register ................................................................................... .......... 335 table 222: duart output port rts register ..................................................................................... ......... 335 table 223: synchronous serial interface signal names .......................................................................... ..... 339 table 224: synchronous serial interface gpio pins ............................................................................. ....... 339 table 225: sequencer table entries ............................................................................................ ................. 341 table 226: hdlc frame structure.............................................................................................. ................. 344 table 227: option flags for synchronous serial transmit channel ............................................................. 34 5 table 228: status flags for synchronous serial receive channel............................................................... 3 49 table 229: recommended line interface settings for loopback mode 2..................................................... 353 table 230: rmon counters ...................................................................................................... .................... 353 table 231: serial mode configuration register................................................................................. ............ 354 table 232: synchronous serial clock source and line interface mode register ......................................... 354 table 233: synchronous serial command register (write-only) .................................................................. 3 55 table 234: serial write threshold register.................................................................................... ............... 356 table 235: serial transmit read threshold register ............................................................................ ....... 356 table 236: serial receive read threshold register ............................................................................. ....... 356 table 237: serial minimum frame size register ................................................................................. ......... 356 table 238: serial maximum frame size register ................................................................................. ........ 357 table 239: serial dma enable registers ........................................................................................ .............. 357 table 240: synchronous serial status register................................................................................. ........... 357 table 241: serial status debug register ....................................................................................... ............... 358 table 242: serial interrupt mask register ..................................................................................... ................ 358 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xxvi document 1250_1125-um100-r table 243: serial address mask register....................................................................................... ...............359 table 244: serial address match register ...................................................................................... ..............359 table 245: sequencer table entries ............................................................................................ .................359 table 246: serial rmon counters ............................................................................................... .................360 table 247: byte lanes for the generic bus ..................................................................................... ..............363 table 248: generic bus timing parameters ...................................................................................... ............366 table 249: burst cycle summary ................................................................................................ ..................372 table 250: generic bus configuration for each boot mode ....................................................................... ...373 table 251: generic bus region configuration registers ......................................................................... .....375 table 252: generic bus region size registers.................................................................................. ...........375 table 253: generic bus region base address registers .......................................................................... ...376 table 254: generic bus region timing 0 registers .............................................................................. ........376 table 255: generic bus region timing 1 registers .............................................................................. ........377 table 256: generic bus interrupt status register .............................................................................. ...........377 table 257: generic bus error data register 0 .................................................................................. ............378 table 258: generic bus error data register 1 .................................................................................. ............378 table 259: generic bus error data register 2 .................................................................................. ............378 table 260: generic bus error data register 3 .................................................................................. ............378 table 261: generic bus error address register 0............................................................................... ..........379 table 262: generic bus erroraddress register 1................................................................................ ..........379 table 263: generic bus error parity register.................................................................................. ..............379 table 264: output drive control register 0 .................................................................................... ...............379 table 265: output drive control register 1 .................................................................................... ...............380 table 266: output drive control register 2 .................................................................................... ...............381 table 267: output drive control register 3 .................................................................................... ...............381 table 268: source for pcmcia card enable signals.............................................................................. ......386 table 269: pcmcia 3.3v and 5v vcc power enable truth table ...............................................................387 table 270: pcmcia vpp power enable truth table ................................................................................ ....388 table 271: example flash card ac specs ........................................................................................ ...........391 table 272: example generic bus timing parameters .............................................................................. .....393 table 273: pcmcia configuration register ..................................................................................... ............394 table 274: pcmcia status register ............................................................................................. ................395 table 275: gpio pins and alternate uses ....................................................................................... .............398 table 276: gpio edge clear register........................................................................................... ................399 table 277: gpio interrupt type register ....................................................................................... ...............399 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r page xxvii table 278: gpio read register................................................................................................. ................... 399 table 279: gpio input invert control register................................................................................. ............. 399 table 280: gpio glitch filter select register ................................................................................. .............. 400 table 281: gpio direction register ............................................................................................ .................. 400 table 282: gpio pin clear register ............................................................................................ ................. 400 table 283: gpio pin set register.............................................................................................. ................... 400 table 284: other pins that can be used as general inputs or outputs ........................................................ 401 table 285: supported smbus transfer types ..................................................................................... ......... 406 table 286: command/address options ............................................................................................ ............ 408 table 287: write data options ................................................................................................. ..................... 408 table 288: read data options .................................................................................................. .................... 409 table 289: smbus clock frequency registers .................................................................................... ......... 416 table 290: smbus command registers ............................................................................................ ........... 416 table 291: smbus control registers ............................................................................................ ................ 416 table 292: smbus status registers............................................................................................. ................. 417 table 293: smbus data registers ............................................................................................... ................. 417 table 294: smbus extra data registers......................................................................................... .............. 417 table 295: smbus packet error check registers................................................................................. ........ 418 table 296: smbus start and command registers smbus mode ................................................................. 418 table 297: smbus start and command registers extended mode ............................................................. 419 table 298: jtag signals....................................................................................................... ........................ 422 table 299: jtag instructions .................................................................................................. ...................... 424 table 300: jtag device id register ............................................................................................ ................ 425 table 301: jtag wafer id register............................................................................................. ................. 426 table 302: system control scan chain .......................................................................................... .............. 428 table 303: performance counter scan chain..................................................................................... .......... 430 table 304: trace control scan chain ........................................................................................... ................ 431 table 305: trace current count scan chain ..................................................................................... ........... 431 table 306: ring oscillator scan chain......................................................................................... ................. 432 table 307: cpu and probe accesses ............................................................................................. .............. 436 table 308: jtag address register scan chain ................................................................................... ........ 439 table 309: data register scan chain ........................................................................................... ................ 439 table 310: ejtag control register ............................................................................................. ................. 440 table 311: internal register addresses by function............................................................................ ......... 446 table 312: internal registers ordered by address .............................................................................. ......... 464 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page xxviii document 1250_1125-um100-r user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 1: introduction page 1 section 1: introduction t he s i b yte b roadband p rocessor f amily the sibyte broadband processors form a family of high performance system-on-a-chip parts targeted at network centric tasks. examples include: in-line packet processing exception processing switch control and management higher layer switching and filtering protocol conversion (voip gateway) network appliances (file servers, web cache, print servers) vpn access, firewalls, gateways the different members of the family target different performance points and applications, while retaining software compatibility. this user manual covers the dual-processor bcm1250, and the uni-processor BCM1125 and BCM1125h parts. all the parts use the sb-1 cpu core. this is a high performance implementation of the standard mips64 instruction set architecture. the core supports a 4-issue enhanced skew pipeline and can dispatch up to two memory and two alu (integer, floating point or mips-3d) instructions per cycle. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 2 section 1: introduction document 1250_1125-um100-r t he bcm1250 the core of the bcm1250 is an on-chip multiprocessor (cmp) system consisting of two broadcom sb-1 high performance mips64 cpus, a shared 512k l2 cache and a ddr sdram memory controller. three integrated 10/100/1000 ethernet macs enable easy interfacing to lans. the three network interfaces can also be operated together to give two 16 bit wide interfaces that can run full-duplex at oc-48 rates. two serial ports are provided for use as uarts or for wan connections at up to t3/oc-1 rates (55mbit/s). high speed i/o is provided using the hypertransport (formerly called ?lightning data transport? or ?ldt?) i/o fabric and a 66 mhz pci (rev 2.2) local bus. to enable low chip count systems the bcm1250 includes a configurable generic bus that allows glueless connection of a boot rom or flash memory and simple i/o peripherals. on-chip debug, trace and performance monitoring functions assist both hardware and software designers in debugging and tuning the system. the system can be run either big endian or little endian. figure 1: bcm1250 block diagram 19.2 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 1: introduction page 3 t he BCM1125 and BCM1125h the core of the BCM1125 and BCM1125h is a uniproce ssor system consisting of a broadcom sb-1 high performance mips64 cpu, a 256k l2 cache and a ddr sdram memory controller. two integrated 10/100/ 1000 ethernet macs enable easy interfacing to lans. the two network interfaces can also be operated together to give a 16 bit wide interface that can run full-duplex at oc-48 rates. two serial ports are provided for use as uarts or for wan connections at up to t3/oc-1 rates (55mbit/s). high speed i/o is provided on the BCM1125h using the hypertransport (formerly called ?lightning data transport? or ?ldt?) i/o fabric. both the BCM1125 and BCM1125h have a 66 mhz pci (rev 2.2) local bus. to enable low chip count systems both parts include a configurable generic bus that allows glueless connection of a boot rom or flash memory and simple i/o peripherals. on-chip debug, trace and performance monitoring functions assist both hardware and software designers in debugging and tuning the system. the system can be run either big endian or little endian. figure 2: BCM1125/h block diagram a udience this user manual includes information that is needed when writing software for the bcm1250, BCM1125 or BCM1125h. it provides a system overview for systems and hardware designers. this user manual is common across the parts, reflecting their software compatibility. each part has an individual data sheet containing detailed hardware information. (note that some hardware details of the bcm1250 that were in previous versions of the user manual are now found only in the data sheet.) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 4 section 1: introduction document 1250_1125-um100-r o ther d ocumentation most of the example designs and application notes for the bcm1250 also apply to the BCM1125 and BCM1125h. documentation useful to users of all the devices includes: sb-1 core processor user manual (sb-1-um00-r) bcm1250 board routability considerations application note (1250-an101-r) bcm1250 generic bus interface to ata/atapi pio mode 3 (ide) hard disk application note (1250- an201-r) bcm1250 dram support application note (1250-an302-r) bcm1250 power supply application note (1250-an4xx-r) bcm1250 design considerations for fast memory systems application note (1250-an5xx-r) bcm1250 big memory system application note (1250-an6xx-r) bcm1250 generic bus interface to 3-volt intel strataflash memory (1250-an7xx-r) hypertransport i/o link specification revision 1.03 from the hypertransport technology consortium pci specification - revision 2.2 mips64 architecture for programmers: http://www.mips.com/publications/index.html - volume i: introduction to the mips64 architecture (md00083) - volume ii: the mips64 instruction set (mips md00087) - volume iii: privileged resource architecture (mips md00091) - volume iv-b: the mdmx ase to mips64 (mips md00095) - volume iv-c: the mips-3d ase to mips64 (mips md00099) mips ejtag specification revision 2.5 corelis application note #00-117 bcm1250 ejtag connector documentation specific to the bcm1250 device includes: bcm1250 data sheet (1250-ds02-r) bcm91250a evaluation card for the bcm1250 product brief (91250a-pb03-r) bcm91250e pci evaluation card for the bcm1250 product brief (91250e-pb01-r) bcm1250 package thermal report (available on request) documentation specific to the BCM1125 and BCM1125h includes: BCM1125/h data sheet (1125h-ds01-r) bcm91125e pci evaluation card for the BCM1125/h product brief (91125e-pb01-r) BCM1125/h package thermal report (available on request) user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 1: introduction page 5 t erminology numbers used in data fields of this document follow the verilog convention of giving the field size in decimal, followed by a quote (?), a character representing the base (b for binary, d for decimal or h for hexadecimal) and the number. thus the decimal number 250 in a 12 bit field will be written as 12?h0fa or 12?b000011111010. block or cache block is used to refer to 32 bytes of data with a base address aligned to a 32 byte boundary (the low 5 address bits are zero). line or cache line is used to refer to the 32 bytes of memory in a cache that holds a cache block. physical addresses are written as 40 bit hexadecimal numbers spaced with underbars (_) for legibility. for example 01_2345_6789 . virtual addresses are only meaningful within a cpu. they are written as 64 bit hexadecimal numbers spaced with underbars (_) for legibility. for example 0123_4567_89ab_cdef . unpredictable operations or behaviors can give arbitrary resu lts, that may differ from device to device or as a function of time on the same device. however, the system will continue to operate and any section that has been placed in an unpredictable state can be restored to deterministic operation under software control. undefined operations or behaviors can result in any outcome from no change in the state of the system to creating an environment in which the system no longer continues to operate. following an undefined operation assertion of the reset signal may be required to restore deterministic operation. register definition tables include the register name and physical address in their titles. the table shows all bits that are implemented. registers are all allocated a 64 bit field, any bits that are not implemented will return unpredictable data if read. the default values show the register value after a system reset. if the default is given as "ext" the value following reset depends on an external pin setting. if no defaults are given the field is unpredictable after reset. reserved register bits and fields are not used in the current device, but may be used in future versions. they must be written with zeros to get the documented behavior and the behavior is undefined if they are written with any other value. future parts may have well defined operation with these bits set. not implemented register bits and fields are not used in the current device and do not have any implementation supporting them. reads will return unpredictable values, writes will have no effect. there is no need to write these bits (for example if the top 32 bits of a register are not implemented then a store word can be used to set the lower bits). read only registers and bit fields provide status information should only be read by the cpus. writes to these fields are ignored. write only registers and locations should be written with data, but cannot be read back. unless otherwise specified, reads will return unpredictable data. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 6 section 1: introduction document 1250_1125-um100-r periph_rev3 refers to the third major revision of the peripherals. these are used in the BCM1125, BCM1125h (all steppings) and later production versions of the bcm1250 (stepping c0 and later, also called ?pass 3?). this manual describes both the periph_rev2 and periph_rev3 revisions and tags information that only applies to periph_rev3. the revision number in the system_revision register can be used by software to determine the available features. note that code written for the earlier parts will work on periph_rev3 parts (provided that it correctly observes reserved fields). an earlier version of the manual should be used for the prototype parts marked bcm12500 which lack some of the peripheral functionality. broadcom use only registers and operations are intended for use by broadcom in testing the device. in most cases this manual does not describe these options in sufficient detail for them to be safely used. incorrect settings of these registers or inappropriate use of operations may cause the system to behave in undefined ways, or require the system to be power cycled to restore operation. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 2: signal overview page 7 section 2: signal overview bcm1250 s ignal g roups the signal pins of the bcm1250 can be divided into functional groups, primarily related to the peripheral to which they are attached. hardware designers should refer to the bcm1250 data sheet for full pinout and timing details. figure 3: bcm1250 signals 28 28 memory m0_clk m0_clk_l m0_cke m0_dq[63:0] m0_ecc[7:0] m0_dqs[8:0] m0_cs_l[3:0] m0_ras_l m0_a[13:0] m0_ba[1:0] m1 (same as m0) hypertransport ldt_tx_cad[7:0] ldt_tx_clk ldt_tx_ctl ldt_rx_cad[7:0] ldt_rx_clk ldt_rx_ctl ldt_pwrok ldt_reset_l pci p_ad[31:0] p_inta_l p_intb_l p_intc_l p_intd_l p_cbe_l[3:0] p_req_l[0] p_req_l[1] / p_idsel p_req_l[3:2] p_gnt_l[0] p_gnt_l[3:1] p_clk p_frame_l p_irdy_l p_trdy_l p_devsel_l p_par p_rst_l generic io_ad[23:0] io_ad[31:24] io_adp[3:0] / gpio[5:2] io_cs_l[7:0] io_wr_l io_oe_l io_ale io_rdy bus s0_din s0_dout s0_cin_rclkin s0_cout s0_cts_tclkin s0_rts_tstrobe s0_tin s0_rin s1 (same as s0) serial ports sda0 scl0 sda1 scl1 smbus mac e0_col e0_crs e0_tclko e0_tclki e0_txd[7:0] e0_txen e0_txer e0_rclk e0_rxd[7:0] e0_rxdv e0_rxer e0_mdio e0_mdc m0_cas_l m0_we_l p_perr_l p_serr_l p_stop_l e1 (same as e0) e2 (same as e0) refck01 refck2 tck tms tdi tdo jtag trst_l clk100p pllbyp reset_l resetout_l clock / misc debug_l tempp gpio gpio[15] / pc_vs2_l 8 8 108 8 2 14 9 8 64 4 2 2 16 16 2 2 32 4 2 3 24 8 4 8 pc_en3v gpio[13] / pc_cd2_l gpio[11] / pc_wp gpio[9] / pc_ready gpio[8] / pc_reset gpio[7] / pc_ce2_l gpio[5:2] / io_adp[3:0] gpio[1] / s1_rstrobe gpio[0] / s0_rstrobe pc_envpp gpio[14] / pc_vs1_l gpio[12] / pc_cd1_l gpio[6] / pc_ce1_l pc_en5v gpio[10] / pc_reg_l 2 e0_geno (shared with generic) 216 pins 46 pins 58 pins 46 pins +4 shared 16 pins 9 pins 5 pins 86 pins 4 pins 15 pins +4 shared ldt_tx/rx_cal 4 m0_vref io_clk100 coldres_l tempn clk100n spare/no connect 4 pins io_rw bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 8 section 2: signal overview document 1250_1125-um100-r BCM1125/h s ignal g roups the signal pins of the BCM1125 and BCM1125h can be divided into functional groups, primarily related to the peripheral that they are attached to. hardware designers should refer to the BCM1125/h data sheet for full pinout and timing details. figure 4: BCM1125/h signals 28 memory m_clk m_clk_l m_cke m_dq[63:0] m_ecc[7:0] m_dqs[8:0] m_cs_l[3:0] m_ras_l m_a[13:0] m_ba[1:0] hypertransport ht_tx_cad[7:0] ht_tx_clk ht_tx_ctl ht_rx_cad[7:0] ht_rx_clk ht_rx_ctl ht_pwrok ht_reset_l pci p_ad[31:0] p_inta_l p_intb_l p_intc_l p_intd_l p_cbe_l[3:0] p_req_l[0] p_req_l[1] / p_idsel p_req_l[3:2] p_gnt_l[0] p_gnt_l[3:1] p_clk p_frame_l p_irdy_l p_trdy_l p_devsel_l p_par p_rst_l generic io_ad[23:0] io_ad[31:24] io_adp[3:0] / gpio[5:2] io_cs_l[7:0] io_wr_l io_oe_l io_ale io_rdy bus s0_din s0_dout s0_cin_rclkin s0_cout s0_cts_tclkin s0_rts_tstrobe s0_tin s0_rin s1 (same as s0) serial ports sda0 scl0 sda1 scl1 smbus mac e0_col e0_crs e0_tclko e0_tclki e0_txd[7:0] e0_txen e0_txer e0_rclk e0_rxd[7:0] e0_rxdv e0_rxer e0_mdio e0_mdc m_cas_l m_we_l p_perr_l p_serr_l p_stop_l e1 (same as e0) refck0 refck1 tck tms tdi tdo jtag trst_l clk100p pllbyp reset_l resetout_l clock / misc debug_l tempp gpio gpio[15] / pc_vs2_l 8 8 8 2 14 9 8 64 4 2 2 16 16 2 2 32 4 2 3 24 8 4 8 pc_en3v gpio[13] / pc_cd2_l gpio[11] / pc_wp gpio[9] / pc_ready gpio[8] / pc_reset gpio[7] / pc_ce2_l gpio[5:2] / io_adp[3:0] gpio[1] / s1_rstrobe gpio[0] / s0_rstrobe pc_envpp gpio[14] / pc_vs1_l gpio[12] / pc_cd1_l gpio[6] / pc_ce1_l pc_en5v gpio[10] / pc_reg_l 2 e0_geno (shared with generic) 108 pins 46 pins 58 pins 46 pins +4 shared 16 pins 10 pins 5 pins 58 pins 4 pins 15 pins +4 shared ht_tx/rx_cal 4 m_vref io_clk100 coldres_l tempn clk100n spare/no connect 6 pins io_rw only on BCM1125h nc on BCM1125 testsig user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 9 section 3: system overview i ntroduction a logical block diagram of the bcm1250 and BCM1125/h family is shown in figure 5 . this figure does not exactly match the implementation details, but it gives a more useful model for programmers and system designers to use. the system is based around the zbbus, a high speed split-transaction multiprocessor bus. it connects the cpu(s), the level 2 cache (l2), the memory controller, two i/o bridges and the system control and debug unit (scd). figure 5: logical block diagram of bcm1250 and BCM1125/h system control & debug performance data l1 inst. l1 l2 ddr sdram ch1 data l1 inst. l1 monitor interrupt mappers timers generic data mover bus trace controller bus error log/counters address trap trace buffer i/o bridge 0 i/o bridge 1 pci host bridge ht host bridge pci bus ht fabric dma mac0 dma mac1 dma serial0 duart ab dma serial1 smbus master generic bus bridge generic bus smb0 smb1 g/mii g/mii serial0 serial1 address/response data jtag zbbus memory controller pcmcia control & gpio pcmcia & gpio sb-1 cpu 0 sb-1 cpu 1 dma mac2 g/mii ht configured as if bridge from pci ch0 only in bcm1250 only in bcm1250 bcm1250, BCM1125h pci & ht BCM1125 only pci only in bcm1250 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 10 section 3: system overview document 1250_1125-um100-r this section gives an overview of the whole system. each of the system elements are described in detail in later sections. the zbbus is the on-chip multiprocessor system bus: data is 256 bits wide, running at half the cpu frequency. (for an 800 mhz part this gives (800/2)*256 = 102.4 gbit/s bus bandwidth). the address is 40 bits (matching the cpu physical address and the hypertransport i/o fabric address). the separate address and data sections are arbitrated for independently, and operate as a split transaction bus. all transactions are tagged, data responses can come back in any order. the cache block ownership protocol (mesi) ensures memory coherence is maintained. individual buffer-full indications from each bus target allow selective flow-control by requestors. the processors are broadcom sb-1 cpus implementin g the mips64 architecture. these are described in detail in the sb-1 user manual. on the bcm1250 the two cpus are identical in all respects apart from the processor number that will be read from the processor identification register (cp0 register 15). the reset logic in the system control and debug unit (scd) is different for the two processors. following a system reset only cpu 0 will be brought out of reset, it can then setup the system and release cpu 1 when ready. in the BCM1125/h parts the processor is cpu 0 and will report that it is a uniprocessor in the processor identification register. the level 2 cache (l2) is organized slightly differently than l2 caches in other systems. it is shared by the processor(s) and any i/o dma masters. it is best understood as a cache on the front of the memory (as shown in figure 5 ), rather than by using the traditional model w here the l2 is associated with a cpu. all memory accesses are checked in the l2. the bus includes a signal to indicate that the data should be allocated in the l2 cache on an l2 miss, this signal may be used by dma masters to write data to the l2 so it can quickly be accessed by the cpu (this has to be done in a controlled way to avoid disrupting the normal gains of having a l2 cache). the i/o bridges isolate the peripherals from the bus, and implement the bus and coherence protocols. they include buffering to allow multiple outstanding i/o requests, and support for dma masters. the pci and hypertransport expansion buses share an i/o bridge, so any peer-to-peer traffic (between pci and hypertransport devices) is hidden from the zbbus. the part can be run as a big endian system or a little endian system. this is set by an input that is read at reset time. internally the few data paths that need to will swap byte lanes, however the system is designed to have as few changes as possible. the cpu endian mode bit (the be bit in the cp0 config register) will always reflect the endian mode of the system. the interface to the pci and hypertransport expansion buses includes byte lane swappers that can be used if required to interface to these devices. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 11 i nternal r egisters there are a large number of internal registers. their definitions are given in the sections of this manual that describe their use. section: ?internal register addresses by function? on page 445 has a summary of all the register addresses. each register is 1 byte, 2 bytes, 4 bytes or 8 bytes. however, even if a smaller size is implemented registers are always allocated in an aligned 8 byte (64 bit) field. most registers can be read or written using a double-word (8 bytes), word (4 bytes), half-word (2 byte) or single byte access. however, some of the registers can only be written with their full width (in these registers a wider write will work, but a narrower write will leave the register value unpredictable). all registers can be read with any size read, if the size requested is larger than the size that is implemented in the register then the extra bits will be filled with unpredictable data (unless otherwise documented). the address given in this manual for all registers is aligned to a double-word (i.e. the final hex digit is a 0 or an 8 ), reflecting the field size rather than the register size. as is illustrated in figure 6 the base address may be used for all access widths in a little endian system. in a big endian system, if the access to the registers is as a double-word the base address should be used, for a word access the address is the base address plus 4, for a half-word access use the base address plus 6 and for a byte access use the base address plus 7. for example, consider a register with 1 valid byte and base address 1234_0000 . its double-word access address is 1234_0000 ; word access address is 1234_0004 ; half-word access address is 1234_0006 ; and single byte access address is 1234_0007 . this fits with the big endian model for data position in double-word fields. figure 6: internal control and status register alignment the internal registers should be referenced by the cpus in uncacheable space, so transactions will never be wider than 8 bytes (and will never span more than a single 8 byte aligned range). one source for initialization errors happens when a bit in a register is defined to have an unpredictable (1?bx) value after reset. it is possible that on all parts used in a small prototype build the bit has the same value, but on a few parts in a larger build it has the other va lue. thus if it is not initialized the error may only be discovered late in the testing process. 70 big endian byte address [2:0] 000 001 010 011 100 101 110 111 little endian byte address [2:0] 111 110 101 100 011 010 001 000 15 0 31 0 63 56 55 48 47 4039 32 31 24 23 16 15 8 7 0 8 bit register 16 bit register 32 bit register 64 bit register bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 12 section 3: system overview document 1250_1125-um100-r when a register is marked as cleared by a read it will be cleared by any read to it. care should therefore be taken to ensure that a compiler or debugger does not split an access to the register into multiple reads. for example if a 64-bit access is split into two 32-bit reads, the first of these reads will get valid data and clear the register and the second will get zeros (compilers will probably do this if they are configured to only use 32-bit registers). similarly, the value of these registers cannot be read from a byte-by-byte memory dump. most (but not all) of the registers with read side effects have an alias (with _debug appended to the register name) that does not have the side effect for a debugger to use. c oherence the system maintains coherence for all memory operations including dma. this coherence means that a read reference to memory space will return the most up to date version of the data. the l2 cache, processors, memory controller and i/o bridges all cooperate to de liver the correct version of each cache block. the coherency is managed by hardware, other than selecting the correct cachability mode no action is needed by software. coherence works at cache line granularity, for each cache block (aligned 32 byte block of memory) there is at all times an owner. the default owner of a block is either the l2 cache or main memory, they work together to service bus requests. blocks that are being shared between bus agents are owned by the l2 or memory. any agent that wishes to modify a cache line must become exclusive owner. when it makes the request the current owner of the block will give it up and any shared copies will be invalidated. although the data transfer may occur at any time following the request, the ownership transfer is deterministic. if an agent receives ownership of a block it is possible that it will lose ownership before it has received the data; in this case it can perform one operation on the block before passing the data to the new owner, this is required to avoid live-lock when two agents are trying to write to the same block. coherent memory references check l1 and l2 tags and the partial- line merge buffer in the i/o bridges at bus speed. if a block is exclusively owned, a request for that line can only be serviced by the owner, if the block is shared it can reside in more than one location, but will be returned from the l2 or memory (as the default owner). when block ownership is transferred (either from one exclusive owner to another, or from an exclusive owner to the default) the data transfer is snooped by the l2/memory so the new owner gets a clean copy of the line. a line in the level 1 cache (in the processor) will be in one of six states: invalid, shared, exclusive clean, exclusive dirty, non-coherent clean or non-coherent dirt y. stores are permitted to all valid lines except for shared ones, which must be upgraded to exclusive before a store is possible. dirty lines will be written back if the line is evicted to make way for a new fill, if evicted due to another device requesting the line (an intervention), or if explicitly written back by software (either a cache instruction forcing write-back, or a prefetch instruction with the nudge hint). lines will only be put in the l1 cache non-coherent if their tlb entry has the cacheable non-coherent cache attribute. these lines will not play a part in the zbbus coherence protocol, and will need careful management by software. in general this should only be done for accessing memory that is genuinely non-coherent, which is true for any memory attached on the pci bus or hypertransport fabric. memory attached on any of these interfaces will not be cached in the l2 cache. memory attached on these is outside the coherency domain: they are i/o connections and do not carry coherency messages, so some other device could update the memory without the cpu being informed that its cached copy is now out of date. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 13 blocks with main memory addresses should be marked coherent in the cpu. if these blocks are not shared there is no difference in performance between marking them cacheable coherent and cacheable non-coherent, but there is a much higher chance of unexpected behavior if the block is marked non-coherent (for example due to false sharing or missing cache flushes before dma operations). when these blocks are used for dma operations the system performance will generally be better if the blocks are marked coherent and the coherence protocol is used to fetch modified data from the cpu cache when it is needed by the dma engine. having the blocks marked non-coherent and using cache oper ations to flush the cache prior to initiating dmas will give a lower system performance as well as being prone to programming errors. lines in the l2 cache are in one of three states: invalid, clean or dirty. all cacheable accesses to the address range controlled by the memory controller check the l2 cache. the coherence mechanism will be circumvented by doing uncached or cacheable non-coherent accesses into memory that has previously been cacheable and coherent. if this is done the results are unpredictable. if areas of memory are never cacheable and coherent then it is the responsibility of software to track ownership. the coherence mechanism can also be circumvented if software uses the invalidate cache operation on a block that is held exclusive in the l1 cache. if a snoop request is received on the bus at the same time this instruction executes, the snoop will hit on the line in the l1 but the line is invalidated before it can be evicted. the cpu will respond by returning unpredictable data marked with a fatal bus error. there is no problem with using the writeback&invalidate cache operation. the generic bus section of memory may be mapped cacheable coherent. the i/o bridge will act as default owner in the mesi protocol (it behaves as the l2/memory does for memory addresses). the cpus are able to take exclusive ownership of cache blocks from memo ry on the generic bus, if ownership is transferred the new owner will acquire the block clean and if needed a writeback will be done to the generic bus. this allows the cache attribute for kseg0 to be set to cacheable coherent to cover both main memory and the boot rom and allows for rams on the generic bus with no special software management. the pci/hypertransport space should not be mapped cacheable coherent. the i/o bridge will respect an ownership assertion by one of the cpus (so there will not be two replies to a read request) but it will not act as default owner and will not copy back dirty data on ownership changes. changes to data may therefore be lost leading to unpredictable behavior. in error cases the behavior of cacheable coherent accesses through i/o bridge 0 is undefined. the i/o bridges provide the entry point into the coherent domain for any dma traffic (from the on-chip network interfaces or pci/hypertransport master devices). the bridges will check the address being accessed. for any memory address cacheable coherent accesses will be used, and partial line writes will cause a read (exclusive)-modify-write cycle. for any address that is not to memory uncacheable accesses are done and partial line accesses will result in only some of the byte enables being set. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 14 section 3: system overview document 1250_1125-um100-r o rdering r ules and d evice d rivers the interaction between the ordering rules imposed by the sb-1 cpu, the zbbus and the peripheral agents simplifies device programming in most situations. in these situations it is the ordering between cacheable coherent memory and uncacheable peripheral registers that is important. the five important rules for the sb-1 are: 1 cacheable coherent stores are visible in program order. 2 uncached loads and stores will issue to the zbbus in program order, and will only issue when all earlier cacheable coherent stores are visible. 3 the cpu will stall until data returns when it needs the result of an uncacheable load (or a cacheable load that has missed in the cache). 4 uncached stores will not issue to the zbbus if there are any uncached loads outstanding. 5 the sync instruction will prevent other instructions from issuing until all outstanding cacheable or uncacheable loads are satisfied, all cacheable stores are visible, all uncacheable stores have been sent on the zbbus, and the write buffer has drained. the internal i/o bridges and peripheral devices have a simple rule: 6 in all queues transactions will remain in the order of zbbus address phase. the pci and hypertransport expansion busses follow the pci ordering rules (appendix e of the pci specification revision 2.2). of particular importance is the rule: 7 posted writes can pass delayed (non-posted) reads. rule ( 1 ) allows the programming style where a processor writes some data and then sets a flag to indicate it is done. another processor polling the flag will always see the new value of the data if it sees the new value of the flag. rule ( 2 ) allows the "flag" to be a peripheral register: memory data (such as dma descriptors or data buffers in cacheable coherent space) can be updated and then a control register (in uncached space) written (for example to start the dma) without the need for any special intermediate operations. note that there is no rule in the other direction; a cacheable coherent store may be visible before an uncacheable load or store that precedes it in program order. if this ordering is required it can be enforced by either using a sync instruction (rule 5 ) or performing and using the result of an uncacheable load (by rule 2 and 3 ). this is important if the processor is using the pci producer-consumer model and is setting a flag in memory to indicate that it has performed a write to a device. when this model is used the uncacheable write to pci or hypertransport space must be flushed from the cpu before the flag is written in cacheable space. the i/o bridge will prevent the read-data-return from the polling request from passing an uncacheable write, so a sync will ensure the uncached write is queued in the bridge before the flag changes. rule ( 6 ) allows there to be multiple outstanding uncached operations. for internal peripherals and the generic bus all requests to the same peripheral will be seen in program order. note that there are no such guarantees between different peripherals (which may be on different zbbus agents, equivalent to being on different pci busses), but this order only matters if there are back-channels between the devices (which will break any ordering rules). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 15 rule ( 7 ) is a potential problem, since writes could pass earlier reads to the same device (and thus the read could see the state after the write completes). however, rule ( 4 ) ensures that this situation never arises for code running on the sb-1. other than blocking this write following read problem, rule ( 4 ) does allow multiple outstanding uncacheable accesses which will reach the peripherals in order. a series of loads performed to a fifo will give the expected results, and by having multiple loads in flight the fifo can be driven at full speed. cacheable non-coherent requests have the same timing as cacheable coherent requests as far as the cpu l1 data cache is concerned. they will be written to the data cache in program order, and the order with respect to uncached operations will be as described above. however, since these requests are outside the coherence domain it is unknown when writes will be visible to the rest of the system (i.e. flushed to l2 or memory and not hidden behind a different cached non-coherent copy of the block). locks can be implemented using the load linked ( ll ) and store conditional ( sc ) instructions. these have additional rules: 8 load linked will not issue speculatively, it is held at the issue point until all preceding instructions have graduated. 9 store conditional includes a partial sync operation. no instructions will be issued from the time the store conditional is issued until it graduates. in most cases no extra sync instructions are needed when acquiring a lock. the load linked is used to check if the lock is free and the store conditional can be used to claim it. if the load indicates that the lock is in use or the store conditional fails the code should spin waiting for the lock (or the process can be blocked, depending on the situation). if the load indicates the lock is free and the store conditional succeeds then the lock has been acquired. there is a potential problem when freeing a lock. a normal store is used to release the lock. however, a sync may be required before the store to force completion of cacheable loads before the lock is released. this will only be the case if loads are performed while the lock is held, but the use of the data is delayed until the lock has been released. consider the case where two loads are done and one hits in the l1 cache but the other misses in the l1 cache and is not used until after the lock is released. the cpu will not stall and (if there is no sync) can therefore execute the write to release the lock. there is a (very small) chance that the other cpu can claim the lock (by getting the line exclusive from the first cpu and having the load linked/store conditional succeed) and modify the data before the load from the first cpu gets the data. thus the first cpu will not see the data that was present when it held the lock, which is probably an error. this can be solved using the sync, or ensuring there is a use of the load before the lock is released (rule 3 ). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 16 section 3: system overview document 1250_1125-um100-r cpu s peculative e xecution the sb-1 cpu can speculatively execute cacheable loads (i.e. a read is issued to the zbbus to get the data before the load is guaranteed to graduate), this only happens if the load is canceled because of an exception on an earlier instruction (branches are always resolved before the load is committed). this is normally not a problem since cacheable reads do not have side effect s. however, the mips kernel address map includes areas where the cacheability attribute is supplied by the address rather than the tlb (kseg0 and xkphys). if a register contains one of these addresses that forces the cacheable attribute then a speculative load may be made to a peripheral address. to protect against this the internal peripherals check the cacheability of reads, and will prevent cacheable reads from having side effects. the generic bus has a mechanism to block cacheable reads which can be enabled for external peripherals that have read side effects (but should normally be disabled for memories). the only space where speculation can cause a problem is therefore the xkphys aliases for pci and hypertransport peripherals. in the absence of program error (i.e. the register just contains the wrong value) there are two reasonable instruction sequences that could cause this behavior if at the start of the sequence the register happens to hold a kseg0 or xkphys cacheable alias of a peripheral. in both cases an exception is used to fix the address for the load. these two sequences can be fixed by adding two superscalar no-ops ( ssnop ) instructions before the loads to ensure the load is not speculatively executed before the exception triggers. a similar situation arises if the ld is replaced with an indirect jump ( jr r1 ), which can put a junk value into the jump register cache and cause a subsequent speculative instruction fetch to issue a cacheable read from a peripheral address. again inserting two ssnop instructions will prevent the problem. the cpu ( break) instruction has a special issue rule, so does not suffer from this problem. it is safe for a debugger to use ( break) to insert breakpoints in the normal way. ; at this point r1 contains junk syscall 73 ; returns address in r1 ld r2, 0(r1) ; this code intends to check r1 before the load tle r1, r2 ; trap if r1 is out of range user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 17 e rror c onditions the system makes every effort to ensure that processing is never done based on erroneous data. error conditions are signalled in several ways, as well as being passed in a flag with the data. all the critical structures where data corruption could occur are protected with ecc (allowing for correction of single bit errors) or parity (in structures that never contain the only copy of the data). as a result of an error condition being detected on data destined for the cpu, it will receive an exception (as required by the mips architecture) and will be signalled interrupts from the source that detected the problem or the bus watcher (see section: ?bus watcher? on page 64 ) or from both source and bus watcher. if the error is detected on data destined for a dma engine, the dma channel will stop and raise an interrupt to the cpu and the bus watcher will report the error. (note that reading the bus watcher status register will clear it and enable logging of future errors, so it should be the last register read when the bus watcher information is dumped.) c ache e rror e xceptions the cache error exception is raised on the cpu both by error conditions detected in the internal caches and by error returns that are flagged on the bus as having data errors (but valid addresses). this follows the mips architecture use of the exception. the practical upshot of this is that code diagnosing the exception should examine the state of external error reporting registers in addition to the ones in the cpu. note that when data is returned to the data cache marked with an error code it will be written to the cache with an uncorrectable ecc error (after ecc is calculated the bottom two bits of each double-word are inverted to force the error) to ensure that it is not used on this processor and that the error is preserved if the line is evicted or snooped out of the cache by another cpu or dma engine. the error registers within the cpu are in the cp0 set and are described in the ?error reporting registers? part of section 9 of the sb-1 user manual. the error control register errctl (register 26, select 0) indicates which cache suffered the error (or was being filled if it is an error signalled over the bus). it also flags recoverable errors from the data cache, these have been corrected and the exception can immediately return unless it needs to gather error statistics. depending on which cache saw the error either cacheerr-i (register 27, select 0) and epc or the cacheerr-d (register 27, select 1) and cacheerr-dpa (register 27, select 3) contain additional information. the external registers are in the bus watcher, the memory error counter ( bus_mem_io_errors ) and l2 error counter ( bus_l2_errors ) indicate how many errors have happened and the bus_err_status register will indicate the type of error and participants involved. because instructions may be issuing and probing the cache at the same time an external error is found on a fill it is possible that an internal error is raised before the external one can be signalled, therefore it is normally useful for debugging if the error reporting code always dumps the bus watcher errors even if it appears to be an internal problem. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 18 section 3: system overview document 1250_1125-um100-r b us e rror e xceptions the bus error exception is raised on the cpu by external errors that are not reporting data corruption. the main cause is when an access is detected to a non-existent address. cacheable accesses that result in a bus error will be put in the cache with uncorrectable ecc errors (as described for the cache error exception). as with cache errors, both cpu and bus watcher registers are useful. the error registers within the cpu are in the cp0 set and are described in the ?error reporting registers? part of section 9 of the sb-1 user manual. the buserr-dpa (register 26, select 1) contains the address of the bus error (or first detected bus error) and the error control register errctl (register 26, select 0) indicates if multiple bus errors have been seen. in the bus watcher the bus error counter ( bus_mem_io_errors ) indicate how many errors happened and the bus_err_status register will indicate the type of error and participants involved. if the bus error is generated from the generic bus (address in the range 00_1009_0000 - 00_3fff_ffff responder id=br1) then the io_interrupt_status register contains more information on the cause of the bus error. again, error reporting code can usefully dump all these registers. there are a couple of interesting corner cases for bus errors. the first occurs when code is executed out of some physical address and at a later time that physical address is no longer valid (this is only likely to happen for unmapped addresses such as kseg0 and xkphys, since the software would presumably have removed any tlb entries that point to invalid physical addresses). for example the generic bus chip select or memory controller address parameters may have been changed. if any branches were executed while the address was valid the cpu will store the branch target information in its branch prediction structures. at a later time it may predict that a branch destination is at the now invalid address and issue a speculative instruction fetch. in this case the cpu will not take a bus error exception (because it will discover the speculation was incorrect), but an interrupt may come in from the peripheral indicating a bad access was made and the bus watcher will record and report that the error passed over the bus (the transaction id recorded by the bus watcher will help indicate this has happened, see table 51: ?decode of some tids for system revision periph_rev3,? on page 81 and section: ?overview of the zbbus protocol? on page 20 ). the second case arises because the bus error exception is imprecise. it can be reported on any instruction from the load that causes the bus error until a few instructions after the use of the register that was the target of the load. in most cases the bus error is a programming error and causes the process to be terminated or the system to enter error recovery. however, in systems with devices that can be hot-swapped the first indication of device removal may be a time out or target abort during an access to the device. in this case the imprecise reporting of the bus error may make it hard to determine that the exception handler should signal the device driver to clean up its state and resume operation ( eret ). one approach to solving this is to have a sync instruction after each load to the hot-swappable device which will force the bus error to be reported on the sync instruction. alternatively, if two ssnop instructions are put after the instruction that uses the target of the load then the bus error will be signalled on one of the instructions between the load and the second ssnop . user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 19 cpu to cpu c ommunication (bcm1250 o nly ) the two cpus in a bcm1250 can communicate and share information in several ways. the mips load linked (ll and lld) and store conditional (sc and scd) instructions can be used to implement atomic operations. when there is genuine sharing, the l1 cache to l1 cache latency is 28-36 cpu cycles. inter-processor interrupts are possible in several ways using a per-cpu mailbox register. this is described in more detail in section: ?mailbox registers? on page 46 . the generating cpu will do a write across the zbbus to the mailbox, which directly raises the receiving cpus interrupt line. the total latency for this is 20-30 cpu cycles plus any context switch time needed. 7-12 of these cycles are taken between the receiving cpus interrupt being raised and its fetching from the exception vector. the interrupt is attached as an exception to a convenient instruction: if the pipeline is running there will immediately be an instruction to use so the shorter time will apply, the longer time is taken when the pipeline is stalled and the instruction that will carry the exception has to be generated. e xternal i nterrupts external interrupts from the pci inputs are synchronized into the internal clock and pass through the interrupt mapper (see section: ?interrupts? on page 47 ) before raising the cpu interrupt input. including the 7-12 cycles in the cpu, there is a latency of 17-22 cpu cycles plus about 2ns from the external pin being asserted to the cpu fetching the first instruction from the exception vector. (note that this is a guideline only, these times are not specified or tested and may vary between parts.) external interrupts from the gpio pins are synchronized and filtered to remove glitches before being passed through the interrupt mapper and to the cpu. when configured for the 60ns glitch filter there is a total latency of 20-25 cpu cycles plus about 112ns from the external pin being asserted and the cpu fetching the first instruction of the exception vector. (note that this is a guideline only, these times are not specified or tested and may vary between parts.) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 20 section 3: system overview document 1250_1125-um100-r o verview of the zb bus p rotocol this section gives an overview of the zbbus protocol. it contains the details needed to do system and performance debugging using the bus trace unit, but is not a full specification for the protocol. the bus is entirely internal to the part, and it connects the main blocks of the system. each block that directly connects to the zbbus is called an agent. figure 5 shows the agents and table 1 lists their four bit bus id number. the bus runs at half the cpu clock speed and can transfer a new request and 256 data bits every cycle. the bus is split into an address section and a data section. these are arbitrated for separately and run independently. for a given transaction, use of the data bus always follows use of the address bus, but there is no other ordering imposed. many transactions can be in progress at a given time. in theory each agent could have 64 outstanding operations on the bus, in practice, t he agents are limited by their internal transaction tracking buffers to fewer than 64. table 2 lists the signals in each section of the bus. table 1: zbbus agent ids agent id description cpu0 0 sb-1 cpu 0. cpu1 1 sb-1 cpu 1. (only in bcm1250) iob0 2 i/o bridge 0, connects pci and hypertransport interfaces to the zbbus. iob1 3 i/o bridge 1, connects the macs and slow speed peripheral interfaces to the zbbus. scd 4 system control and debug unit. 5 reserved l2c 6 l2 cache. mc 7 memory controller. table 2: zbbus signals address/control section a_ad[39:5] address of cache block moved by the request. the byte enables complete the address. a_byen[31:0] byte enables. a_byen[31] corresponds to d_ da[255:248], down to d_byen[0] which corresponds to d_da[7:0]. (see tab l e 5 ) a_id[9:0] transaction id: [9:6] are requester agent id (see tab le 1 ). [5:0] are unique for that requester. a_cmd[2:0] command (see ta b l e 3 ). a_l1ca[1:0] l1 (base) cache attribute (see table 4 ). a_l2ca request that the l2 cache allocate on miss. r_shd[5:0] response indicating block is shared. each agent drives the bit corresponding to its id. r_exc[5:0] response indicating block is exclusive. each agent drives the bit corresponding to its id. r_l2hit response indicating block is in the l2 cache. this signal is only used following a read command, but is also valid for most writes. this signal my be incorrect following writes to the l2 registers, or after an uncorrectable tag ecc error. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 21 each transaction is marked with a transaction id (tid), a 10 bit number constructed by the requester. the top four bits of the tid are the requester's agent number (given in table 1 ), and the lower six bits are chosen by the requester to be unique for all transactions it has in progress (see also section: ?magic decoder ring for using the trace buffer? on page 81 ). the bus supports coherent and non-coherent transactions. the bulk of the protocol is used to track ownership of coherent blocks and implement the standard mesi coherent states: m - modified. this block is dirty (has been updated, and is different from memory). modified is a subset of exclusive, an agent must be exclusive owner before changing the data. e - exclusive. the agent that has this data is the only agent that has it. this agent is permitted to modify the block. s - shared. the line is present in multiple agents, but is clean (memory or the l2 cache has the most current update). no agent may modify the block. i - invalid. the block is not present in a particular agent. a transaction on the bus involves three phases and two arbitrations. 1 the requesting agent arbitrates for the address bus. the bus will be granted in a fair manner. 2 the address phase (a-phase) starts the transaction. 3 the response phase (r-phase) gathers the coherency state for the transaction and thus determines which agent is responsible for providing the data. ownership transfers at the end of the r-phase. 4 the agent providing the data arbitrates for the data bus. 5 the data phase (d-phase) transfers the associated data and ends the transaction. normally an agent only arbitrates for the bus when it is prepared to make a transaction. however, occasionally agents (particularly the cpus) will speculatively request the bus and then discover the transaction has been canceled. in this case the agent will still use the bus cycle, but issues a nop command. an a-phase nop will also be caused if the previous cycle on the bus was a transaction for the same address or if the destination agent blocks transactions as the source agent is granted the bus. a rbitration the zbbus arbitration uses a fair history based system. requests are granted based on the last time the agent was granted the bus. if all agents request every cycle (this never happens because the bus bandwidth is much higher than the i/o device bandwidths) this will become a simple round robin scheme. in practice most agents request the bus ahead of needing it thus hiding the arbitration cycle. data section d_da[255:0] data. there is valid data only on the byte lanes that had byte enables set (on a_byen) in the a-phase. the data on the other byte lanes is unpredictable. d_id[9:0] transaction id (copied from associated a_id). d_code[2:0] data status/error code (see tab l e 6 ). d_rsp[3:0] agent id of the agent driving the data bus (see ta b l e 1 ). d_mod set to indicate the data is modified (dirty). table 2: zbbus signals (cont.) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 22 section 3: system overview document 1250_1125-um100-r a ddress p hase in the address phase the requesting agent puts the tid, address, byte-enables, command and cache attributes onto the address bus. all agents will examine the request and respond by setting their r_shd and r_exc bits in the r-phase. the address has cache block granularity, and is therefore bits [39:5] of the physical address being accessed. thirty-two byte enables indicate which bytes within the block are to be transferred. the bus commands are in table 3 . uncached and non-coherent accesses use the same commands, but will be responded to by the agent that owns the address. the default owner of a block is the l2 or memory controller for all addresses in the memory address space, the generic bus is the default owner for addresses in the generic bus range. table 3: zbbus commands a_cmd[2:0] command action data bus read_shd 000 read shared the block is provided by the current owner and becomes shared. if the current owner is l2/memory and no other agent has a shared copy then the acquiring agent may take exclusive ownership (with no other action). data will be supplied by the exclusive owner if one is identified in the response phase, otherwise the default owner will supply it. read_exc 001 read exclusive the block is provided by the current owner and becomes exclusively owned by the acquiring agent. all other copies of the block are invalidated. data will be supplied by the exclusive owner if one is identified in the response phase, otherwise the default owner will supply it. write 010 write the block is written back to l2/memory. data will be supplied by the requester. write_inv 011 write invalidate the requesting agent acquires ownership of the block and invalidates all copies (even if they are dirty), it then releases ownership and writes the block back to l2/memory. this is an optimization that avoids the need for a read_exc and transfer of data that will be discarded, it is used when the requesting agent is overwriting a complete block with new data (for example when a packet is dmaed from the network). data will be supplied by the requester. invalidate 100 invalidate block the requesting agent acquires ownership of the block and all copies are invalidated (even if they are dirty). it is used when an agent upgrades a shared line to exclusive (in which case none of the copies will be dirty), or if the agent needs to become exclusive owner and guarantees to overwrite the complete line. there is no data phase for this command. 101 reserved 110 reserved nop 111 no operation this command is used when the agent arbitrated for the bus and was granted, but is unable to complete the transaction. this will happen occasionally if the access is blocked by a buffer becoming full between the time the agent requested the bus and the address phase. it can also happen as a result of an exception in the requesting agent. there is no data phase for this command. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 23 two fields describe the cache attributes of a transfer. the first, shown in table 4 , describes the base (level 1 cache) attribute. this must be set consistently by all agents using a block or all accesses to the block become unpredictable. the second attribute is only used for cacheable transactions that have an address in the memory controller range. the a_l2ca (level 2 cache allocate) signal indicates that the block should be allocated in the l2 cache if it misses. following the d-phase of a transaction with this attribute the data will always be in the l2 cache. note that this attribute only controls the behavior on a cache miss: all cacheable accesses to the memory controller range are checked in the l2 cache, reads will always be serviced by the l2 if they hit and writes will always update the l2 if they hit. r esponse p hase the response phase determines which agent will supply the data for a read command and is the point of ownership transfer for a block. following the r-phase the new owner is responsible for the block (even if it does not yet have the data). each agent has r_exc and r_shd status signals. it asserts the r_exc signal to indicate it has exclusive ownership of the block and that it will provide read data. it asserts the r_shd signal to indicate it has a shared copy of the block. the memory controller and l2 cache use these to determine if they must supply or accept the data. the requesting agent will examine the status after doing a read (shared) command, if no other agent has a shared copy of the data then the requesting agent is permitted (but not required) to take exclusive ownership of the block as if it had issued a read exclusive command. an agent can assert both r_exc and r_shd to indicate an error. this is done if there is a parity or ecc error in the tags and the agent is unable to determine if it has ownership. if an exclusive owner can be identified then it supplies the block as normal. if there is no other exclusive owner then the memory controller will respond with unpredictable data marked with a fatal error. the l2 cache will assert the r_l2hit to indicate to the memory controller that it will act as the default owner for the block. the default owner supplies data for a read if there is no exclusive owner, and captures the data on a write or ownership transfer. table 4: zbbus level 1 cache attributes a_l1ca[1:0] attribute 00 cacheable non-coherent. the block will be cached but will not play a part in the coherence protocol. any agent with a copy of the block is free to write it. software must manage the coherence. 01 cacheable coherent. the block will be cached and uses the full coherence protocol. during usual operation all blocks with main memory addresses should use this attribute. 10 uncacheable. the data will not be cached, and will not play a part in the coherence protocol. (although not required, this attribute is normally used for uncacheable data that consists of 8 bytes or less.) 11 uncacheable. the data will not be cached and will not play a part in the coherence protocol. (although not required, this attribute is normally used for uncacheable data that has been merged in a buffer and may therefore be any number of bytes.) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 24 section 3: system overview document 1250_1125-um100-r d ata p hase the data transfer ends a transaction, and takes place in the data phase. since the latency between the a- phase request and the data becoming available can be very long, the d-phase is completely decoupled from the a-phase. the transaction id is used to tie the data to the corresponding request. an agent must always be prepared to accept the data; it must not issue a read command unless it has space to accept the read-data- return, and it must block all writes when its receive buffers are full. the d-phase takes place on the data section of zbbus. a separate fair arbiter is used to get control of the data lines. the d-phase must always follow the a-phase, so agents are not permitted to arbitrate for the data bus until they have been granted the address bus. the data bus signals, shown in table 2 , include the actual data being sent (data smaller than a block is sent on its natural byte lanes) and status information. the byte lanes that data uses on the zbbus depends on the system endian mode. when viewed as 64 bit double-words there is no change (i.e. address bits [4:3] always select which 64 bit section of the zbbus is used), but the byte address within the 64 bit double-words is swapped when the endian mode changes. table 5 shows the mapping from byte address to data bits and byte enables. the d_code indicates the status of the data being transferred as shown in table 6 . table 5. zbbus byte lane assignments data bits 22 5-4 58 22 4-4 70 22 3-3 92 22 3-2 14 22 2-1 36 22 1-0 58 22 0-0 70 11 9-9 92 11 9-8 14 11 8-7 36 11 7-6 58 11 6-6 70 11 5-5 92 11 5-4 14 11 4-3 36 11 3-2 58 11 2-2 70 11 1-1 92 11 1-0 14 10 0-9 36 00 9-8 58 00 8-8 70 00 7-7 92 00 7-6 14 00 6-5 36 00 5-4 58 00 4-4 70 00 3-3 92 00 3-2 14 00 2-1 36 00 1-0 58 00 0-0 70 byte enable 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 big endian addr[4:0] (hex) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f little endian addr[4:0] (hex) 07 06 05 04 03 02 01 00 0f 0e 0d 0c 0b 0a 09 08 17 16 15 14 13 12 11 10 1f 1e 1d 1c 1b 1a 19 18 table 6: zbbus data status codes d_code[2:0] status of data on d_da sources of error 000 nop, data invalid (gets counted as arbitrated but not used). this is used if an agent was granted the data bus but some exception causes it to be unable to supply the data. all agents can generate nops. 001 data valid. all agents can generate valid data. 010 data valid, tag was corrected for ecc error. l2 cache: tag ecc corrected. 011 data valid, data was corrected for ecc erro r. cpu: data cache had correctable error. memory controller: data ecc corrected. l2 cache: data ecc corrected. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 25 if an error is signalled during a data transfer the system takes care to maintain the error condition. if bad data is sent to the l2 cache or memory controller an uncorrectable ecc pattern is written with the data, so that subsequent reads will also see an error and bad data will not be used in processing. this can lead to a cascade of errors during the period between the initial detection of an error and software recovery code running (the scd error log will record the first problem). the d_mod signal is asserted if the data being transferred is dirty (i.e. differs from l2/memory). in this case the l2 cache or memory controller will take a copy of the data, so that the new owner receives it clean. the memory controller and l2 cache work together to supply data for any of the memory regions of the address space. figure 7 shows the decision process that is used on reads and writes to the memory region to determine which agent supplies the data and which accepts write data. it also shows which of the memory or l2 will write back data when dirty data is supplied by an exclusive owner. 100 bus error. a cpu will take a bus error exception if it receives this error. i/o bridge0: pci parity error, master or target abort. hypertransport nxa or error return. i/o bridge1: generic bus error (no chip select for the address, time-out during an access or i/o bus parity error). memory controller: no chip select decoded for the address. scd: the scd will return this error with unpredictable data if the bus watcher detects an illegal address. 101 fatal bus error. the ownership of the block is unclear. this can be caused by a cpu tag parity error, or because software used a cacheop to invalidate an exclusive line and the cpu had committed to supply the line in the window while the operation executed. a cpu will take a bus error exception if it receives this error. memory controller: the memory controller returns unpredictable data with this error code if an agent asserts both r_shd and r_exc. i/o bridge1: this error code is returned with unpredictable data and the io_coh_err bit will be set if some agent asserts both r_shd and r_exc during a coherent generic bus access. 110 uncorrectable ecc error in the tag. a cpu will take a cache error exception if it receives this error. cpu: tag parity error. l2 cache: tag ecc error. 111 uncorrectable ecc error in the data (l2 cache or memory controller). a cpu will take a cache error exception if it receives this error. cpu: data cache had uncorrectable data ecc error. memory controller: data ecc error. l2 cache: data ecc error i/o bridge: write of a read-modify-write operation that received an uncorrectable data error during the read. table 6: zbbus data status codes (cont.) d_code[2:0] status of data on d_da sources of error bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 26 section 3: system overview document 1250_1125-um100-r figure 7: decision tree for memory space address accesses r eset the coldres_l input is used for power-on reset of the device. it must be held low until the power supplies are within the operating range and the reference clock is stable. the cold reset will read the pll multiplier bits and start the pll, an internally generated delay allows the pll to lock before the system is started. at the end of the cold reset delay reset time configuration info rmation is read from the generic bus io_ad lines (see below). the reset_l input is used to cause a warm reset of the device, this resets all the internal logic but does not restart the pll, read the configuration information or wait the cold reset delay (reset_l need not be asserted at power-on since the cold reset delay has higher precedence). the end of the cold reset sequence or the deassertion of reset_l signal starts the internal reset sequence to establish the internal state, the scd will then release the system and cpu0. the device will source the reset signal for the board (resetout_l), the pci bus (p_rst_l) and the hyper transport fabric (ldt_reset_l and ldt_pwrok if the link needs a cold reset). these are all driven during the internal reset period and other than p_rst_l can be asserted separately under software control. reset can also be initiated by software or time-out of the watchdog timers. these can be a soft reset which restarts the part but is not signalled externally or a system reset which will assert resetout_l. the software initiated system reset will re-sample the configurati on information (except for the pll ratio), the watchdog system reset will not. memory read error condition -some agent is unable to determine ownership memory controller returns fatal error l2 cache read memory read read shared or exclusive (memory space address) exclusive owner supplies data write or write & invalidate (memory space address) l2 cache write memory write s h d & e x c l2 hit l 2 m i s s e x c e x c & s h d memory write l2 write if hit u n c a c h e a b l e l1 c a c h e a b l e l 2c a u n c ac h e able or l2mas t er c a c h e a b l e ( i n c l u d e s n o n - c o h e r e n t ) n o t l 2 c a l2 cache write memory write l2 write if hit l 2c a n o t l 2 c a data modified user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 27 table 7 summarizes the reset options. during reset pull-up and pull-down resistors on the generic address/data bus are used to set static system options. these pins have weak internal pull-up or pull-down resistors (as described in the hardware data sheet), external resistors are required to set the other state. these options change the behavior of pins that need to be active at startup time to ensure proper operation. table 7: operation of different reset sources coldres_l pin asserted software system reset system_cfg[60] watchdog 2nd time-out type=system reset_l pin asserted software soft reset system_cfg[58] watchdog 2nd time- out type=sbsoft sample pll_div bits restart pll clear system_cfg[63] y- --- - sample configuration bits (other than pll_div) yy --- - assert resetout_l y y y y - - reset zbbus y y y y y y reset agents y y y y y y table 8: static configuration options io_ad bit name pulled up to 3.3v pulled down section 0 reserved reserved normal operation. n/a 1 clk100_src the internal 100mhz clock and io_clk100 come directly from the clk100_p reference. the io_clk100 will have a duty cycle only a little worse than the reference clock. the internal 100mhz clock and io_clk100 are generated by dividing down the output of the pll that feeds the cpu clock. the io_clk100 will match the internal clocking and will run at a few mhz (typically less than 10mhz) during coldres_l. section: ?clocks? on page 31 2 ldt_minrstcnt broadcom use only. enable hypertransport reset test mode. normal operation. n/a 3 ldt_bypass_pll broadcom use only. bypass the hypertransport pll. normal operation. n/a 4 pci_test_mode broadcom use only. enable pci test mode. normal operation. n/a 5 iob0_div iob0 clock is cpu clock/3 use with slow cpu clocks. iob0 clock is cpu clock/4 use with fast cpu clocks. section: ?clocks? on page 31 6 iob1_div iob1 clock is cpu clock/2 use with slow cpu clocks. iob1 clock is cpu clock/3 use with fast cpu clocks. section: ?clocks? on page 31 11:7 pll_div these bits are used to set the pll clock ratios section: ?clocks? on page 31 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 28 section 3: system overview document 1250_1125-um100-r 12 ser0_enable serial port 0 is synchronous. serial port 0 is uart a. section: ?synchrono us mode? on page 336 this sets the reset configuration, software may change it. 13 ser0_rstb_en gpio[0] is driven as s0_rstrobe by serial port 0. gpio[0] is a gpio pin. section: ?synchrono us mode? on page 336 14 ser1_enable serial port 1 is synchronous. serial port 1 is uart b. section: ?synchrono us mode? on page 336 this sets the reset configuration, software may change it. 15 ser1_rstb_en gpio[1] is driven as s1_rstrobe by serial port 1. gpio[1] is a gpio pin. section: ?synchrono us mode? on page 336 16 pcmcia_enable pcmcia controller enabled. gpio[15:6] are used by the pcmcia logic. io_cs_l[6] is pcmcia select. pcmcia controller disabled. gpio[15:6] are gpio pins. io_cs_l[6] is a general chip select. section: ?introductio n? on page 421 17 boot_mode[0] the io_cs_l[0] region of the generic bus space that is used for the boot rom is configured for non-multiplexed operation with 8 data bits and 24 address bits. the smbus eeprom boot is configured for large (> 16 kbit) eeproms using the eeprom read word protocol. the io_cs_l[0] region of the generic bus space that is used for the boot rom is configured for multiplexed operation with 32 data bits and 32 address/enable bits. the smbus eeprom boot is configured for small (<= 16 kbit) eeproms using the read word protocol. section: ?configurin g a chip select region? on page 36 2 section: ?booting using an smbus eeprom? on page 412 18 boot_mode[1] the boot address will access an eeprom on the smbus. the boot address will access a rom on the generic bus. section: ?boot rom support? on page 37 2 . section: ?booting using an smbus eeprom? on page 412 . 19 pci_host the pci interface is run as the host bridge. the pci interface is run as a regular device. section: ?introductio n? on page 190 . 20 pci_arbiter the pci interface uses the internal arbiter. this must not be set if bit [19] is pulled down. the pci interface uses an external arbiter. section: ?pci arbiter? on page 222 . 21 southonldt the south bridge is on the hypertransport fabric or on a bus bridged from the hypertransport fabric. the south bridge is on the pci bus. section: ?the southbridge, vga and subtractive decode? on page 19 5 . if there is no south bridge this bit may be set either way. 22 big_endian the system is big endian. the system is little endian. section: ?introductio n? on page 9 . 23 genclk_en enables output of the generic bus clock on the io_clk100 pin. set the io_clk100 pin to a high impedance state. section: ?generic bus timing? on page 364 . table 8: static configuration options (cont.) io_ad bit name pulled up to 3.3v pulled down section user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 29 after a system reset (or power-on reset) cpu 0 and all peripherals are brought out of reset, but on a bcm1250 cpu 1 continues to be held in reset and will be isolated from the system. this allows cpu 0 to perform essential system initialization before releasing cpu 1. since both cpus have the same reset vector (virtual ffff_ffff_bfc0_0000 , physical 00_1fc0_0000 ) the initial code will probably branch based on the cpu number which can be read from the prid cp0 register. the boot address is in the space that the i/o system uses for the generic expansion bus. at reset time this is configured to allow access to a (slow) boot rom or flash memory, or can be diverted to smbus interface 0, which will fetch code from a serial eeprom. (a debugger may use the ejtagboot option to cause the cpu to fetch the boot code from the jtag port as described in section: ?ejtagboot instruction? on page 425 .) following reset, no coherent accesses should be made until the data cache tags in the cpu(s) and the l2 cache tags have been invalidated. the dma controllers and requests from the expansion buses can use coherent accesses, so they must not be used until the tags have been cleared. on a single cpu, once the level 1 cache tags have been invalidated cacheable non-coherent accesses may be done to the boot memory space. it is recommended that cpu 0 invalidates its cache tags and the l2 cache tags prior to releasing cpu 1 from reset, cpu 1 should clear its tags and signal cpu 0 that coherent accesses may be used. it is possible to independently reset the cpus, either from software or the watchdog timers. this is a potentially hazardous operation since while in reset the cpu is removed from participation in the coherence protocol. when the cpu goes in to reset it may be in the process of supplying data and releasing a exclusive lock on a line, since these operations are aborted some other agent may hang waiting for the data or lock. when the cpu is released from reset it will have stale coherency information in its caches and software initialization will clear all state. the independent reset features can be used to implement error recovery when one cpu fails while maintaining availability by allowing the other to continue to operate, but very careful consideration must be given to the possible state of the system if this is done (or it may be optimistically done with the fall-back position of a full reset if the partial restart fails). 24 ldt_test_en broadcom use only. enable hypertransport test mode. normal operation. n/a 25 gen_parity_en parity is enabled on the generic bus. gpio[5:2] are used by the generic bus controller. parity is not used on the generic bus gpio[5:2] are gpio pins. section: ?generic bus parity? on page 363 . 31:26 config sampled at reset time and available in the scd configuration register. these bits can be interpreted by software for system configuration. n/a table 8: static configuration options (cont.) io_ad bit name pulled up to 3.3v pulled down section bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 30 section 3: system overview document 1250_1125-um100-r a controlled reset of a running cpu can be done in a safe way. first the data cache must be flushed by doing indexed-writeback-invalidate cache ops on all entries in the cache. secondly, it must be ensured that the data for all evicts has been sent to the bus (rather than just being visible). after these steps, the cpu will not be involved in any coherent operations and can be safely reset. the sequence of operations can be summarised: the first sync will ensure all the index-writeback-invalidate operations have completed and the cpu will not hit for any future snoops, but up to two writebacks may still be in transit in the bus interface buffers. the uncached stores will queue behind the writebacks, and the second sync ensures they have reached the bus buffers and therefore the writebacks have completed. at this point it is safe for the cpu to write to its reset bit. the data cache state is not affected by reset, so when the cpu comes out of reset the cache (and duplicate tags used by snoops) will still have all entries invalid. if the cpu has been shutdown using this sequence it is therefore safe to release it from reset in a system that is already running with coherent accesses. the different actions of the resets may be used to identify which reset happened. a sequence similar to the following could be used (this assumes that the device uses a uart on port 0 for the console but the io_ad[12] is set for synchronous port). index wb invalidate over whole dcache sync uncached store to somewhere that does not matter uncached store to somewhere that does not matter sync uncached store to reset bit // first check the sw_flag. it is only cleared by coldreset if system_cgf.sw_flag == 0 resettype = coldreset // next check for the software initiated full reset, this resamples // the configuration bits so will set the synchronous port else if system_cfg.ser0_enable == 1 resettype = softwaresystemreset // next check for a soft reset, since the bit is not self-clearing // it will still be set else if system_cfg.sb_softres == 1 resettype = softwaresbsoftreset // no internal way to tell between an external reset_l // and a watchdog timeout else resettype = resetlorwatchdog // later bcm1250 have a flag for watchdog reset if bcm1250 stepping c0 or later if watchdog wd_has_reset bit set resettype = watchdog else resettype = reset // now set conditions for the next time // and allow use of the uart, set not-coldreset flag, clear softres system_cfg.ser0_enable = 0 system_cfg.sw_flag = 1 system_cfg.sb_softres = 0 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 31 the system_scratch register could be used as an alternative to using the configuration bit for the serial port. the software would have to put a unique value into the r egister (or could set a bit that is reserved for this purpose) before writing the system_reset bit. c locks the device is provided with a 100 mhz clock from which it generates the other internal clocks. the clock is multiplied up with a pll to provide the cpu clock, which is divided down to provide the internal bus clocks and memory clock. a separate pll is used to generate the hypertransport clocks. an internal 100mhz clock is generated either directly from the reference clock or by dividing the cpu clock by the pll ratio to drive the internal timers, the baud rate generator and for the timing parameters on the generic bus. the internal 100 mhz clock may be driven out on the io_clk100 pin. using the reference source ensures that for all pll ratios the io_clk100 will have a duty cycle only a little worse than the reference clock and that the io_clk100 runs at the same 100mhz frequency as the reference clock during cold reset and while the pll locks. using the internally generated reference ensures that the io_clk100 tracks the internal clocks (it will run slowly during cold reset even if the reference clock has not started), and if an integer pll ratio is used (i.e. io_ad[7] was sampled low) ensures the duty cycle is no worse than 40:60 regardless of the reference clock. however, if a nonintegral pll ratio is used only the rising edge of the internally generated io_clk100 is valid, the time the output spends high can vary from cycle to cycle and be as short as 10% of the cycle. the pci bus and network interfaces have their own bus clocks that must be externally generated to match the attached components. the synchronous serial port cloc k either comes from the baud rate generator or from an external source. table 9 shows the supported clock ratios for the cpu and hypertransport interface. note that the speed grade of the part determines the maximum frequency that is permitted. the ratio for the cpu is set statically using the reset value on io_ad[11:7] as described in the previous section. the ratio for the hypertransport may be set directly (by enabling an extension register in the hypertransport configuration space), but is normally set indirectly by encoding the value from the hypertransport link frequency register. table 9: core and hypertransport clock settings code ratio main pll (code from reset time io_ad[11:7]) hypertransport pll (code from hypertransport frequency register) cpu clock (mhz) zbbus clock (mhz) hypertransport clock (mhz) hypertransport data rate (mbps/pair) 00100 2x 200 100 200 400 00101 2.5x 250 125 250 500 00110 3x 300 150 300 600 00111 3.5x 350 175 350 700 01000 4x 400 200 400 800 01001 4.5x 450 225 450 900 01010 5x 500 250 500 1000 01011 5.5x 550 275 550 1100 01100 6x 600 300 600 1200 01101 6.5x 650 325 01110 7x 700 350 01111 7.5x 750 375 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 32 section 3: system overview document 1250_1125-um100-r the clocks for the i/o bridges that connect the peripherals to the zbbus (see figure5onpage9 ) are synchronously divided down from the cpu clock. the divide ratio needs to be set as part of the reset time configuration (see section: ?reset? on page 26 ) based on the cpu frequency. the i/o bridge clock does not affect the speed of the peripheral interfaces directly, but it does affect the bandwidth (and latency) between the peripheral and the zbbus. increasing the bridge clock speed will increase the bandwidth, but will use more power. conversely the speed can be decreased to save power if the full bandwidth is not needed. i/o bridge 0 is designed for operation with the clock about 200 mhz, it should be set in the range 166-266 mhz (check the data sheet for the maximum frequency for a given speed grade). i/o bridge 1 is designed for operation with the clock about 266 mhz, it should be set in the range 233-333 mhz (check the data sheet for the maximum frequency for a given speed grade). the maximum frequency for the bridge clocks is given in the data sheet as fbr0 and fbr1 in the clock, reset and test timing parameters. 10000 8x 800 400 10001 8.5x 850 425 10010 9x 900 450 10011 9.5x 950 475 10100 10x 1000 500 10101 10.5x 1050 525 10110 11x 1100 550 table 9: core and hypertransport clock settings (cont.) code ratio main pll (code from reset time io_ad[11:7]) hypertransport pll (code from hypertransport frequency register) cpu clock (mhz) zbbus clock (mhz) hypertransport clock (mhz) hypertransport data rate (mbps/pair) user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 33 the memory clock is synchronously divided down from the cpu clock. the divide ratio is programmed into the memory controller configuration registers. figure 8 gives an overview of the internal clock generation. . figure 8: clock distribution overview ht pll (see table 23) core pll x2-x11 (see table 23) external 100 mhz reference pci_clk refclk01 refclk2 s0_tclk, s0_rclk s1_tclk, s1_rclk sync serial interface (some modes) pci controller mac 0, mac 1, fifo 0 mac 2, fifo 1 interface clocks asynchronous to 100 mhz reference core clock to cpu0, cpu1, l2 cache ht internal clock zbbus clock m0 clock m1 clock ht clock gpio glitch filter generic bus timing clock for watchdog timers clock for generic timers baud clk0 baud clk1 scl0 scl1 baud rate a baud rate b smbus0 mem channel 1 mem channel 0 sstl-2 sstl-2 lvds 1-4096 100 1-4096 2,2.5,3,3.5,4,4.5 2,2.5,3,3.5,4,4.5 8 20 20 2 iob1 2, 3 iob0 3, 4 clk100 2-11 as pll i/o bridge 0 logic i/o bridge 1 logic 4 ht io_clk100 genclk_en clk100_src(from io_ad[1]) i/o 2 2 io_ad[23] only on bcm1250 refclk0 refclk1 mac 0, fifo mac 1 bcm1250 BCM1125/h not on BCM1125 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 34 section 3: system overview document 1250_1125-um100-r m emory m ap the memory map is designed to be usable in systems that only have 32 bit addressing and to provide expansion for systems that can support the full 64 bit virtual address and 40 bit physical address of the sb-1 cpu. there are some additional restrictions that the mips architecture imposes: the reset vector of the cpu is to physical address 00_1fc0_0000 . the exception vectors of the cpu are at physical address 00_0000_0000 . (they may be offset from the base by a multiple of 64k using the sb-1 multiprocessor vector extension in the cpu config register). the first 512 mb of memory is addressable uncached (and unmapped) in kseg1 and is therefore a good place for fixed address peripherals (they can be accessed without using any tlb entries). in addition devices on the pci need to be able to dma into all of the physical memory (within the 32 bit pci address range) and be able to enable or disable endian swapping on each transaction (see section: ?endian policies? on page 201 for a full discussion of pci and hypertransport endian policies). an overview of the memory map is given in table 10 and figure 9 and a more detailed view is in table 11 on page 36 . table 10: overview of bcm1250 physical address map base top owner 00_0000_0000 00_0fff_ffff memory controller. 00_1000_0000 00_1005_ffff system control and debug. 00_1006_0000 00_3fff_ffff i/o system. 00_4000_0000 00_5fff_ffff hypertransport/pci memory mapped i/o (32 bit addressing range) match byte lane endian policy. 00_6000_0000 00_7fff_ffff hypertransport/pci memory mapped i/o (32 bit addressing range) match bit lane endian policy. 00_8000_0000 00_9fff_ffff memory controller. 00_a000_0000 00_bfff_ffff reserved 00_c000_0000 00_cfff_ffff memory controller. 00_d000_0000 00_d7ff_ffff l2 controller test. 00_d800_0000 00_d92f_ffff hypertransport special operations match byte lane endian policy. not on BCM1125. 00_dc00_0000 00_ddff_ffff hypertransport/pci i/o space match byte lane endian policy. 00_de00_0000 00_dfff_ffff hypertransport/pci configuration space match byte lane endian policy. 00_e000_0000 00_f7ff_ffff reserved 00_f800_0000 00_f92f_ffff hypertransport special operations match bit lane endian policy. not on BCM1125. 00_fc00_0000 00_fdff_ffff hypertransport/pci i/o space match bit lane endian policy. 00_fe00_0000 00_ffff_ffff hypertransport/pci configuration space match bit lane endian policy. 01_0000_0000 7f_ffff_ffff memory controller expansion. 80_0000_0000 f7_ffff_ffff hypertransport expansion (40 bit addressing range). not on BCM1125. f8_0000_0000 f8_ffff_ffff pci bus full access (match byte lane endian policy). f9_0000_0000 f9_ffff_ffff pci bus full access (match bit lane endian policy). fa_0000_0000 fc_ffff_ffff reserved fd_0000_0000 ff_ffff_ffff reserved (special hypertransport range). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 35 the memory controller supports up to 1 gb of memory in a system that is restricted to 32-bit physical addresses, and up to 4 gb ( 2 gb on BCM1125/h) using 512 mb technology drams (up to 8 gb when 1gb technology sdrams are available, and with an option to double the size at the cost of speed with an external decoder) on systems with a full 40-bit address. the address map includes 512 mb for mapping pci and hypertransport memory mapped peripherals that use 32-bit addressing, and an alias for this space that will byte swap accesses when the system is in big endian mode. accesses to reserved or unused regions will result in unpredictable behavior. writes will be discarded. figure 9: memory map system control and debug first sdram region boot rom internal devices reserved pci/ht config 01_0000_0000 00_a000_0000 00_0000_0000 sdram expansion maps to 00_d800_0000 - 00_dfff_ffff with "match bit" endian policy pci/ht i/o space ht/pci special l2 direct access fourth sdram region third sdram region second sdram region pci/ldt memory space match bit lane endian policy 00_1000_0000 00_1006_0000 00_1009_0000 generic bus devices (default for io_cs0) 00_1fc0_0000 00_2000_0000 00_4000_0000 00_6000_0000 00_8000_0000 00_9000_0000 pci/ldt memory space 00_f800_0000 00_e000_0000 00_de00_0000 00_dc00_0000 00_d800_0000 00_d000_0000 00_c000_0000 match byte lane endian policy reserved ht devices reserved 80_0000_0000 f8_0000_0000 ff_ffff_ffff pci full access fa_0000_0000 not on BCM1125 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 36 section 3: system overview document 1250_1125-um100-r table 11: address map details base top size owner use 00_0000_0000 00_0fff_ffff 256 mb mc base dram. 00_1000_0000 00_1001_ffff 2*64 kb scd reserved/debug jtag serviced addresses. 00_1002_0000 00_1002_0fff 4 kb scd reset config, cpu 0 interrupt mapper, timers, addr trap, trace, bus log and counters. 00_1002_1000 00_1002_1fff 4 kb scd scd cpu 0 mailbox alias. 00_1002_2000 00_1002_2fff 4 kb scd cpu 1 interrupt mapper. (reserved on BCM1125/h) 00_1002_3000 00_1002_3fff 4 kb scd cpu 1 mailbox alias. (reserved on BCM1125/h) 00_1002_4000 00_1002_ffff 48 kb scd reserved 00_1003_0000 00_1003_ffff 64 kb scd zbbus cycle count. 00_1004_0000 00_1004_ffff 64 kb scd/l2 l2 registers. 00_1005_0000 00_1005_ffff 64 kb scd/mc memory controller registers. 00_1006_0000 00_1006_00ff 0.25 kb i/o smbus, gpio. 00_1006_0100 00_1006_01ff 0.25 kb i/o duart ch a. 00_1006_0200 00_1006_02ff 0.25 kb i/o duart ch b. 00_1006_0300 00_1006_03ff 0.25 kb i/o duart status and control. 00_1006_0400 00_1006_07ff 1 kb i/o sync serial, dma and hdlc ch 0. 00_1006_0800 00_1006_0bff 1 kb i/o sync serial, dma and hdlc ch 1. 00_1006_0c00 00_1006_0fff 1 kb i/o unused 00_1006_1000 00_1006_17ff 2 kb i/o generic bus config. 00_1006_1800 00_1006_1fff 2 kb i/o generic bus status and log, pcmcia config and status. 00_1006_2000 00_1006_2fff 4 kb i/o reserved 00_1006_3000 00_1006_3fff 4 kb i/o unused 00_1006_4000 00_1006_4fff 4 kb i/o mac 0. 00_1006_5000 00_1006_5fff 4 kb i/o mac 1. 00_1006_6000 00_1006_6fff 4 kb i/o mac 2. (on BCM1125/h: alias of mac 0; do not use!) 00_1006_7000 00_1006_ffff 36 kb i/o unused 00_1007_0000 00_1008_ffff 2*64 kb i/o reserved 00_1009_0000 00_3fff_ffff 767 mb i/o generic/boot interface. 00_4000_0000 00_5fff_ffff 512 mb pci/ht memory mapped i/o space. match byte lane endian policy. 00_6000_0000 00_7fff_ffff 512 mb pci/ht memory space mapped i/o space. match bit lane endian policy. 00_8000_0000 00_8fff_ffff 256 mb mc second dram bank. 00_9000_0000 00_9fff_ffff 256 mb mc third dram bank. 00_a000_0000 00_bfff_ffff 512 mb xx unused 00_c000_0000 00_cfff_ffff 256 mb mc fourth dram bank. 00_d000_0000 00_d7ff_ffff 128 mb l2c l2 special test address range. match byte lane endian policy. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 37 00_d800_0000 00_d8ff_ffff 16 mb ht eoi signaling.match byte lane endian policy. (reserved on BCM1125) 00_d900_0000 00_d90f_ffff 1 mb ht iack signaling. match byte lane endian policy. (reserved on BCM1125) 00_d910_0000 00_d91f_ffff 1 mb ht system management. match byte lane endian policy. (reserved on BCM1125) 00_d920_0000 00_d92f_ffff 1 mb ht n/a 00_d930_0000 00_dbff_ffff 45 mb ht reserved 00_dc00_0000 00_ddff_ffff 32 mb pci/ht i/o space (only 25 bits). match byte lane endian policy. 00_de00_0000 00_deff_ffff 16 mb pci/ht configuration space. match byte lane endian policy. 00_df00_0000 00_dfff_ffff 16 mb pci/ht reserved 00_e000_0000 00_efff_ffff 256 mb xx unused 00_f000_0000 00_f7ff_ffff 128 mb xx unused 00_f800_0000 00_f8ff_ffff 16 mb ht eoi signaling. match bit lane endian policy. (reserved on BCM1125) 00_f900_0000 00_f90f_ffff 1 mb ht iack signaling. match bit lane endian policy. (reserved on BCM1125) 00_f910_0000 00_f91f_ffff 1 mb ht system management match bit lane endian policy. (reserved on BCM1125) 00_f920_0000 fd_f92f_ffff 1 mb ht n/a 00_f930_0000 00_fbff_ffff 45 mb ht reserved 00_fc00_0000 00_fdff_ffff 32 mb pci/ht i/o space (only 25 bits). match bit lane endian policy. 00_fe00_0000 00_feff_ffff 16 mb pci/ht configuration space. match bit lane endian policy. 00_ff00_0000 00_ffff_ffff 16 mb pci/ht reserved 01_0000_0000 7f_ffff_ffff 508 gb mc dram expansion space. 80_0000_0000 f7_ffff_ffff 480 gb ht hypertransport devices. (reserved on BCM1125) f8_0000_0000 f8_ffff_ffff 4 gb pci pci full address range. match byte lane endian policy. f9_0000_0000 f9_ffff_ffff 4 gb pci pci full address range. match bit lane endian policy. fa_0000_0000 fc_ffff_ffff 12 gb pci reserved fd_0000_0000 fd_f7ff_ffff 3968 mb ht reserved (hypertransport reserved space). fd_f800_0000 fd_f8ff_ffff 16 mb ht reserved (interrupt signaling). fd_f900_0000 fd_f90f_ffff 1 mb ht reserved (iack signaling). fd_f910_0000 fd_f91f_ffff 1 mb ht reserved (system management). fd_f920_0000 fd_f92f_ffff 1 mb ht reserved (preq protocol). fd_f930_0000 fd_fbff_ffff 45 mb ht reserved fd_fc00_0000 fd_fdff_ffff 32 mb ht reserved (pci i/o). fd_fe00_0000 fd_ffff_ffff 32 mb ht reserved (pci configuration). table 11: address map details (cont.) base top size owner use bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 38 section 3: system overview document 1250_1125-um100-r fe_0000_0000 ff_ffff_ffff 8 gb ht reserved table 11: address map details (cont.) base top size owner use user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 3: system overview page 39 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 40 section 3: system overview document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 41 section 4: system control and debug unit i ntroduction the system control and debug unit (scd) includes all the system control functions, interrupt mappers, system level performance monitoring, and debugging functions. s ystem c ontrol the system controller is used to bring the part out of reset. it holds the reset-time configuration options and contains the extended jtag interface that allows external control and monitoring of the system. the jtag interface is described in detail in section: ?tap controller? on page 421 . the basic scan chain has been extended to allow an external debugger access to a selection of internal state both in the cpus and in the system. the jtag interface can access system debug and performance monitoring features such as the performance counters and the zbbus trace logic. no software support on the target system is required to run this debugging interface. system reset is controlled by this section of the scd. the external coldres_l pin must be asserted at system power-up and can be asserted later to cause a cold reset of the system. the reset_l pin can be used to cause a warm reset of the system. the scd generates all the required internal reset pulses and timing and drives the external reset output resetout_l. there are two registers associated with the system controller. one is the system_revision register which identifies the part and gives the chip revision number. the second is the system configuration register system_cfg which reports the states of the reset time configuration options and allows resetting of various sections of the system. the system_cfg register is accessible both from the system and from the jtag port. a cpu can cause a system reset by setting the system_reset bit of the system_cfg register. this will behave the same as the coldres_l pin of the part being asserted (except the pll is not restarted), and is the standard way for software to cause a full restart. the restart will clear the system_reset bit. the sb_softres bit is identical except the system_cfg register bits are not restored to their defaults (note that this bit does not self clear). software may use the other bits of the register to reset an individual cpu or signal an external reset. to prevent lockup, the cpu 0 reset bit automatically clears. jtag access to the register may also manipulate the reset bits, in this case they do not automatically clear so the jtag probe has full control of the resets. the jtag probe can also reset individual zbbus agents. while reset is asserted the agent is isolated from the system, in this state any access to the agent will hang. the lower bits of the system_cfg register reflect the state that was latched from the generic bus io_ad pins at reset time. these are described in section: ?reset? on page 26 . some of these are used to configure device pin options, others are free for interpretation by system software (for example the board revision could be read in this way). many bits of the system_cfg port are only writable from the jtag port. they provide access to test features and are reserved for use by broadcom. they must be left at zero for normal operation of the part. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 42 section 4: system control and debug unit document 1250_1125-um100-r the uniprocessor bits and soft-reset bit may be used on the bcm1250 to disable one of the processors. the clock to the disabled processor will be stopped following reset and it will enter a low power state (lower power than being left in reset). the processor will be enabled on the next full reset (reset_l pin asserted, system_reset bit written with a one or a watchdog double timeout). following a full reset only cpu0 will be running and cpu1 will be held in reset. if a uniprocessor system is desired, the cpu0 reset sequence should check for a multiprocessor environment by reading the multiprocessor bit in the prid (cpu cp0 processor id register) or the uniprocessor bits in the system_cfg register. if the system is running as a multiprocessor the unicpu0 bit should be set in the system_cfg register, and the sb_softres bit written with a one to cause the system to reboot as a uniprocessor. the system_scratch register is a read/write register that is not used by the hardware. it is free for software use. for example it may be used by firmware to store a pointer to bootstrap information for use by the operating system, or it may be used to pass (small) messages between the processors before memory is configured. the value of the register is unpredictable following cold reset, the value is preserved over other resets. the sw_flag bit in the system_cfg register may be used to indicate the validity of the scratch value, since the flag is cleared on a cold reset and preserved over other resets. the sw_flag may also be used by the system to distinguish between cold resets and others. software can check the bit after reset: if the bit is zero then the reset was a cold reset and the bit should be set, if the bit is already set then the reset was some other type (also see section: ?reset? on page 26 ). table 12: system identification and revision register system_revision - 00_1002_0000 read only bits name default description 7:0 reserved 8'hff reserved, reads as 8'hff. 15:8 revision xx revision of the part. see ta b l e 1 3 . 31:16 part xx part type. bcm1250 16'h1250 16'h1150 (configured as uniprocessor) 16'h1125 (configured as uniprocessor, half l2 aka 1125y) BCM1125 16'h1123 BCM1125h 16'h1124 bits 27:24 indicate the number of processors. bits 23:20 indicate the l2 cache size (1-128kb, 2-256kb, 5-512kb, 0-1024k). bits 19:16 indicate the peripheral set (0,2,5 - bcm1250 peripherals, 3 - BCM1125 peripherals, 4 - BCM1125h peripherals). 63:32 wid xx wafer id. table 13: part revisions part stepping peripherals revision nickname comment bcm12500 an periph_rev1 8?h01 or 8?h02 ?pass1? prototype only parts, refer to earlier manual. bcm1250 an periph_rev2 8?h03 - 8?h0b ?pass2? inital production bcm1250 parts. bcm1250 bn periph_rev2 8?h10 or 8?h11 ?pass2.2? bcm1250 cn periph_rev3 8?h20 ?pass3? bcm1250 with peripherals upgraded BCM1125/h an periph_rev3 8?h20 or 8?h21 ?pass1? initial production BCM1125/h parts BCM1125/h bn periph_rev3 8?h30 ?pass2? user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 43 table 14: manufacturing information register system_manuf - 00_1003_8000 read only bits name default description 63:0 mid xx manufacturing id. broadcom use only. table 15: system configuration register system_cfg - 00_1002_0008 bits name default description 0 reserved ext read only, reflects the strap resistor on io_ad[0]. 1 clk100_src ext read only, reflects the strap resistor on io_ad[1] that selects the source for the internal 100mhz clock and io_clk100 (if enabled). 2 ldt_minrstcnt ext read only, reflects the strap resistor on io_ad[2]. broadcom use only. this must be zero for normal operation. 3 ldt_bypass_pll ext read only, reflects the strap resistor on io_ad[3]. broadcom use only. this must be zero for normal operation. 4 pci_test_mode ext read only, reflects the strap resistor on io_ad[4]. broadcom use only. this must be zero for normal operation. 5 iob0_div ext read only, reflects the strap resistor on io_ad[5] that controls the clock divider for i/o bridge 0. 0: iob0 runs at cpu clock/4, for use with fast cpu clocks. 1: iob0 runs at cpu clock/3, for use with slow cpu clocks. 6 iob1_div ext read only, reflects the strap resistor on io_ad[6] that controls the clock divider for i/o bridge 1. 0: iob1 runs at cpu clock/3, for use with fast cpu clocks. 1: iob1 runs at cpu clock/2, for use with slow cpu clocks. 11:7 pll_div ext read only, reflects the strap resistors on generic io_ad[11:7] that select the pll divide ratio. 12 ser0_enable ext read/write. the default reflects the strap resistor on generic io_ad[12] but this bit can be written by software to change the setting. 0: serial interface 0 is in asynchronous (uart) mode. 1: serial interface 0 is in synchronous mode. if this bit is changed by software it must also re-initialize the interface. 13 ser0_rstb_en ext read only, reflects the strap resistor on generic io_ad[13] that allocates gpio[0] pin to the synchronous serial interface. 14 ser1_enable ext read/write. the default reflects the strap resistor on generic io_ad[14] but this bit can be written by software to change the setting. 0: serial interface 1 is in asynchronous (uart) mode. 1: serial interface 1 is in synchronous mode. if this bit is changed by software it must also re-initialize the interface. 15 ser1_rstb_en ext read only, reflects the strap resistor on generic io_ad[15] that allocates gpio[1] pin to the synchronous serial interface. 16 pcmcia_enable ext read only, reflects the strap resistor on generic io_ad[16] that configured the pcmcia mode. 18:17 boot_mode ext reflects the strap resistor on generic io_ad[18:17] that configured the boot mode. 00: 32 bit generic bus rom (multiplexed) 01: 8 bit generic bus rom (non-multiplexed) 10: smbus eeprom <= 16 kbit (read word protocol) 11: smbus eeprom > 16kbit (eeprom read word protocol). bit 17 is read only. bit 18 can be changed by software to clear the smbus boot mode and allow general use of the smbus 0 interface. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 44 section 4: system control and debug unit document 1250_1125-um100-r 19 pci_host ext read only, reflects the strap resistor on generic io_ad[19], that configures the pci interface to be host or device mode. 20 pci_arbiter ext read only, reflects the strap resistor on generic io_ad[20], that configures the pci interface to use an internal or external arbiter. (if the pci is set in device mode the resistor must be set for an external arbiter) 21 southonldt ext read only, reflects the strap resistor on generic io_ad[21], that configures the southbridge to be on the hypertransport fabric or pci bus. 22 big_endian ext read only, reflects the strap resistor on generic io_ad[22], that configures the system to be big or little endian. 23 genclk_en ext read only, reflects the strap resistor on generic io_ad[23], that enables output of the generic bus clock on io_clk100. if this bit is zero then the io_clk100 will be held in a high impedance state. 24 ldt_test_en ext read only, reflects the strap resistor on io_ad[24]. broadcom use only. this must be zero for normal operation. 25 gen_parity_en ext read only, reflects the strap resistor on generic io_ad[25] that configured the generic bus parity. 31:26 config ext read only, reflects the strap resistor on generic io_ad[31:26]. these configuration bits are available for interpretation by software. 32 clkstop 1'b0 writable via jtag only. broadcom use only. 33 clkstep 1'b0 writable via jtag only. broadcom use only. 41:34 clkcount 8'b0 writable via jtag only. broadcom use only. 42 pllbypass 1'b0 writable via jtag only. broadcom use only. 44:43 pll_iref 2'b0 writable via jtag only. broadcom use only. 46:45 pll_vco 2'b0 writable via jtag only. broadcom use only. 48:47 pll_vreg 2'b0 writable via jtag only. broadcom use only. 49 mem_reset 1'b0 writable via jtag only. when set the memory controller is held in reset. 50 l2c_reset 1'b0 writable via jtag only. when set the level 2 cache is held in reset. 51 io_reset_0 1'b0 writable via jtag only. when set the i/o bridge to the pci and hypertransport fabric is held in reset. 52 io_reset_1 1'b0 writable via jtag only. when set the i/o bridge to the slow speed devices and generic bus is held in reset. 53 scd_reset 1'b0 writable via jtag only. when set the scd is held in reset. 54 cpu_reset_0 1'b0 always reads as zero. when written with a 1 a standard length reset pulse is delivered to cpu 0. (a device reset will also cause a standard length reset pulse to cpu 0). 55 cpu_reset_1 1'b1 when set cpu 1 will be held in reset. this bit is set on a device reset, causing the processor to remain in reset until released under software control. 56 unicpu0 1'b0 set to indicate uniprocessor using physical processor 0. (this bit will always be set on the BCM1125/h.) 57 unicpu1 1'b0 set to indicate uniprocessor using physical processor 1. (bcm1250 only) 58 sb_softres 1'b0 when a write changes this bit from a 0 to a 1 a soft reset will be performed. this will reset of whole chip except for this register. note that once it is set the bit must be cleared before writing a 1 will again cause a soft reset. 59 ext_reset 1'b0 when set the resetout_l pin will be asserted. table 15: system configuration register (cont.) system_cfg - 00_1002_0008 bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 45 60 system_reset 1'b0 when written with a 1 a full system reset will be performed (thus setting this bit back to zero). 61 misr_mode 1?b0 broadcom use only. 62 scd_misr_reset 1?b0 broadcom use only. 63 sw_flag 1?bx this read/write bit is cleared by a cold reset. its value is preserved on any other reset. it may be used by software to detect the reset type, or for any other use. table 15: system configuration register (cont.) system_cfg - 00_1002_0008 bits name default description table 16: scratch register system_scratch - 00_1002_0c10 bits name default description 63:0 value 64'hx this register is available for any use by software. when the chip is powered up its value is unpredictable. its value is preserved over reset. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 46 section 4: system control and debug unit document 1250_1125-um100-r m ailbox r egisters each cpu has a mailbox register that can be used to signal events or small messages. the register may be accessed by the other cpu (on a bcm1250) or a bus master peripheral. if the part is a device on the pci bus (i.e. not the host bridge) then the host on the pci can use the mailbox to signal the cpu. a mailbox register is 64 bits wide and has four in terrupt lines, for each group of 16 bits the corresponding interrupt is raised whenever any bit is set. to set a bit in the mailbox a 1 must be written to the appropriate bit position in the mbox_set location. to clear a bit in the mailbox a 1 must be written to the appropriate bit position in the mbox_clear location. thus there is no need for an atomic read-modify-write. typically only the cpu which owns the register would write the clear register and the signalling agent would write the set register. however, there is no protection in the hardware to enforce this (any agent that can access the mbox_set and mbox_clear locations can change the mailbox state). the interrupt outputs from a particular mailbox are only routed to the interrupt mapper of one cpu, thus cpu0 cannot be interrupted by the setting of bits in mailbox_1 and cpu1 cannot be interrupted by the setting of bits in mailbox_0 . interrupts from the hypertransport interface can set bits in the mailbox, allowing peripherals to signal events. this is setup by the way the peripheral interrupts are configured by the system software. the system software determines the use of the mailbox register and the meaning associated with each of the bits. other than the mapping from bit positions to interrupt lines the hardware imposes no restrictions. the simplest way to use the mailbox is as sixty-four event channels grouped into four (or fewer) priority levels. the signalling agent writes to set the event bit and the signaled cpu can clear it when it has responded. one or more of the four interrupts will be raised whenever there are outstanding events in the mailbox. this is likely to be the best method to use if high speed i/o interrupts will be feeding the mailbox. at the other extreme, each of the quarters of the mailbox could be considered a channel for passing 16 bit messages. an example use is in inter-processor procedure calls. the source of the call will marshal arguments into a shared memory buffer, then make the call by writing the buffer index to the mailbox set location. this raises an interrupt on the service processor, which will read the buffer index from the mailbox and write the mailbox clear location. since the shared memory buffer is coherent the service processor will always see the correct data, and the ordering imposed by the write-in terrupt cleanly transfers buffer ownership. when the procedure is completed the results could be passed back using the reverse mechanism. in addition to the normal address, the mbox_set and (read only) mailbox locations have aliases that are the only registers in a 4k page. this page is accessible from the pci interface (through bar2 for the cpu 0 mailbox and bar3 for the cpu1 mailbox). thus pci devices can only set bits in the mailbox (to signal the cpu) or read the current mailbox status (to see if a signal was cleared), but can never clear the mailbox. the cpu (or any other agent in the part) can access all the mailbox registers and can therefore both set and clear bits. table 17: mailbox registers mailbox_cpu_0 - 00_1002_00c0 , alias_mailbox_cpu_0 - 00_1002_1xx0 (read only) mailbox_cpu_1 - 00_1002_20c0 , alias_mailbox_cpu_1 - 00_1002_3xx0 (read only) 63 48 47 32 31 16 15 0 mbox_int_0 if any bit set mbox_int_1 if any bit set mbox_int_2 if any bit set mbox_int_3 if any bit set mbox_set_cpu_0 - 00_1002_00c8 , alias_mbox_set_cpu_0 - 00_1002_1xx8 (write only) mbox_set_cpu_1 - 00_1002_20c8 , alias_mbox_set_cpu_1 - 00_1002_3xx8 (write only) when this location is written, any bits that are set will cause the corresponding bit to be set in the mailbox register. mbox_clr_cpu_0 - 00_1002_00d0 (write only) mbox_clr_cpu_1 - 00_1002_20d0 (write only) when this location is written, any bits that are set will cause the corresponding bit to be cleared in the mailbox register. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 47 i nterrupts the chip has a large number of interrupt sources. these come from both internal peripherals and external signals. each cpu has its own interrupt mapper which allows the destination of the interrupt from each source to be set to one of the six architected hardware interrupts, the non-maskable interrupt (nmi) or the debug interrupt (dint). the mapper block includes the cpu mailbox registers described in the previous section. most interrupt sources are common to each interrupt mapper. the only sources that are specific to a cpu are directed interrupts from the hypertransport (as described below, the interrupt message includes which cpu it should be delivered to) and the per-cpu mailbox interrupts. the basic operation of the interrupt mapper is described in this section. interrupts from the hypertransport fabric extend the basic model as described in the next section. section: ?the full interrupt mapper? on page 50 has a diagram of the complete mapper, including system, mailbox and hypertransport sources and describes all the associated registers. the interrupt mapper receives the level sensitive interrupts from all sections of the part. each source has an associated mask bit and a 3 bit map register. if the source is interrupting and not masked out it is driven to one of the cpu interrupt lines according to the mapping. table 18 shows the mapping, and the corresponding ip bit in the cause register. each source maps to one cpu interrupt line. there is no limit on how many sources may map to a single cpu line. the i5 interrupt line is also used by interrupts generated internal to the cpu, these will be merged with any external requests. the mips architecture uses software based interrupt dispatch, so the software can assign priorities to the six regular interrupt lines as it sees fit. a typical system would merge most of the system sources on a few of the interrupt lines, and assign one source per line for sources that need rapid dispatch. table 18: interrupt mappings mapping interrupt cp0 cause register 000 i0 ip[2] bit 10. 001 i1 ip[3] bit 11. 010 i2 ip[4] bit 12. 011 i3 ip[5] bit 13. 100 i4 ip[6] bit 14. 101 i5 ip[7] bit 15. 110 nmi reset/nmi vector, flagged in status register not cause register. 111 dint cpu debug interrupt, flagged in debug register. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 48 section 4: system control and debug unit document 1250_1125-um100-r to assist software dispatch there are status registers associated with each of the six cpu interrupt lines, dint and the nmi. these indicate which sources are interrupting, pass the mask and are routed to this interrupt line. in addition there is a global status register that shows which sources are interrupting regardless of their mask setting or routing. the debug interrupt (dint) to the cpu may be raised by the interrupt mapper. it will also be raised if a trace trigger is marked to send dint (see section: ?trigger sequences? on page 73 ) or if the break control bit is set in the ejtag control register (see section: ?ejtag control register? on page 439 ). there is a diagnostic register built into the interrupt mapper that can be used to force interrupts to be asserted into the mask and map logic. since there is a full copy of the mapper fo r each cpu, system interrupts may be masked and mapped differently on the two processors. in many cases a particular source would always be assigned to a particular processor, delivering it to both requires software to coordinate servicing the interrupt. h yper t ransport i nterrupts the hypertransport bus protocol includes passing interrupt messages across the hypertransport fabric. these messages include identification of the interrupt vector (as described below there are some non-vectored interrupts, carrying meanings specific to the x86 architecture, but these are thought of as having an implicit vector number in the interrupt mapper). the mips architecture does not directly support hardware interrupt vectoring, so the vector number is used by the hardware to decide which input to the interrupt mapper will be triggered and software can do any required vectoring. the interrupt packet also includes a destination. this is either a physical processor number or "a system specific logical mapping". the bcm1250 cpus (and their related interrupt controllers) are physically numbered 0 and 1. the BCM1125h cpu (and interrupt controller) is physical number 0. the logical mapping used is the example one from the hypertransport specification, a proc essor is selected as the target by setting the bit position corresponding to its physical processor number. this scheme allows for up to eight processors. use of the logical mapping allows broadcast and multicast interrupts (having only two cpus, these amount to the same thing on the bcm1250). the mapper supports the 8 bit destination from the hypertransport specification rev 1.0 and earlier, and will ignore the additional 24 destination bits added by the hypertransport specification rev 1.01. the hypertransport interrupt messages must maintain ordering with transactions that come across the hypertransport link ahead of them. they therefore follow the same flow as other hypertransport transactions and are delivered to the scd across the zbbus as writes to the interrupt_ldt_set register. writes to this register are decoded and used to set bits in either the mailbox register or the interrupt_ldt register. the cpu can write the interrupt_ldt_set register during testing to simulate the arrival of an interrupt message. the data written is a 64-bit double-word containing the data from the hypertransport interrupt message as described in table 19 . user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 49 the hypertransport defines three sorts of interrupts: non-vectored interrupts carry a type field rather than source vector information. they are used to carry interrupt messages that are traditionally associated with pins on the x86 cpu. the five types are smi (system management interrupt), nmi (non maskable interrupt), init (initialize processor, on x86 resets integer registers but does not affect fp or caches), startup (used to start application processors in x86 multiprocessor systems) and ext. int. (external interrupt, used to signal an interrupt from a pic style pc interrupt controller). these are statically mapped to source vectors h32 - h36 before being reported to the interrupt mapper of the cpu(s) to which they are directed. fixed interrupts are the standard form. they include the destination information and the source vector and are delivered to all interrupt mappers to which they are directed. arbitrated (low priority) interrupts behave the same as fixed interrupts. however if multiple destinations are indicated they only get delivered to one of them. the hypertransport specification requires that the destination selected is either the lowest priority or the cpu that is currently servicing an interrupt from the same source. since mips architecture cpus give no external indication of which interrupt they are currently servicing the mapper implements this by delivering the interrupt to the lowest numbered cpu to which it is directed. all hypertransport interrupts are thus presented to the interrupt mapper as an 8 bit vector number. the top two bits of the vector number are used to determine how the low 6 bits are used: table 19: interrupt message format for writes to interrupt_ldt_set register data bits description 2:0 hypertransport interrupt message type: 000: fixed 001: arbitrated (low priority) 010: non-vectored: smi 011: non-vectored: nmi 100: non-vectored: init 101: non-vectored: startup 110: non-vectored: external interrupt 111: reserved 3 hypertransport interrupt trigger mode 0=edge, 1=level (non-vectored interrupts must be edge). 4 hypertransport interrupt destination mode 0=physical, 1=logical. 12:5 hypertransport interrupt destination. 20:13 hypertransport interrupt vector. table 20: delivery of hypertransport interrupts vector[7:6] delivery of vector[5:0] 00 the bit corresponding to vector[5:0] in the interrupt_ldt register is set, raising that interrupt line to the mapper. 01 the bit corresponding to vector[5:0] in the mailbox register is set, raising one of the mailbox interrupts to the mapper. 10 interrupt will be discarded. 11 interrupt will be discarded. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 50 section 4: system control and debug unit document 1250_1125-um100-r hypertransport interrupt messages specify if the source is edge or level sensitive. edge sensitive interrupts do not need to be acknowledged, and it is source dependent whether the cpu has to take action before further interrupts can be signalled. level interrupts require the cpu to send an eoi message to acknowledge the servicing of the request. the interrupt source device will wait until an eoi is received before issuing any further interrupts. in the mips architecture the cpu does not produce a signal to indicate eoi. software must do a write to the eoi space at the end of the interrupt service routine (see section: ?hypertransport end of interrupt (eoi) signaling space? on page 198 ). since the hypertransport specification requires that edge and level interrupts are not reported with the same source vector id, software will know from the vector number that an eoi is needed. the access to the eoi space must be a write, so the cpu is not stalled while the request is issued. (reads to eoi space have undefined results.) interrupts from a pc style pic interrupt controller are signaled using the external interrupt message, which has no additional source information associated with it. the pic will provide an 8-bit source vector in response to an interrupt acknowledge (iack) cycle. on the bcm1250 and BCM1125h software is responsible for running the iack cycle by performing a byte read within the reserved iack range as described in section: ?legacy interrupt acknowledge (iack) space? on page 199 . a read to this address range gets routed to the southbridge. if the southbridge is a native hypertransport device, then this command packet will be routed directly to the southbridge. if the southbridge is connected to a pci device bridged from the hypertransport then the command packet will be routed to the intervening hypertransport-pci bridge. (if the southbridge is on the pci interface (set by the southonldt configuration bit being clear) the iack access will be run as a pci iack cycle, but in that case the interrupt would not have come in as a hypertransport external interrupt message.) t he f ull i nterrupt m apper the full interrupt controller is illustrated in figure 10 on page 51 . this shows the mailbox and hypertransport sources and all the mapper registers. the system sources and the mailbox interrupts come into the interrupt_source_status register. they are combined with the hypertransport interrupts and the data in the interrupt_diag register. this is a read/write register that the cpu can use to activate interrupt r equest lines. it is primarily used to allow testing of the interrupt routing by simulating device interrupts. the interrupt_ldt register bits are set by the hypertransport interrupt controller as described in the previous section. the register is read by the cpu to determine the hypertransport interrupt source and cleared by a write to the ldt_interrupt_clear register. the interrupt_mask register is used to block interrupts. masking is done after the three sources (system, hypertransport and diagnostic) have been combined, if interrupt lines are shared either all sources are masked off or none. all unmasked interrupts are passed to the interrupt mapper. this has a 3 bit map register for each of the sources which maps the source to one of the cpu interrupt lines (regular int[5:0], nmi or dint). each source can be mapped to only one cpu line, but each cpu line can have any number of sources. the regular interrupt signals to the cpu and dint are level sensitive and will continue to be asserted as long as there are interrupting sources. the nmi is edge triggered and will be asserted for a single cycle whenever the mapper output asserts (i.e. after an nmi all interrupting sources must be clear for at least a cycle before a subsequent nmi will be generated). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 51 the interrupt_trace register is used to select which interrupts to this cpu are sent to the trace unit to be used as part of a trigger condition. the bits in this register provide an accept mask. any interrupt that has its corresponding bit set in this register will cause the trigger. figure 10: per-cpu interrupt mapper (replicated for each cpu; x = 0 or 1) interrupt_trace_x (64 bits) mbox_clr_cpu_x (64 bits) mbox_set_cpu_x (64 bits) mailbox_cpu_x (64 bits) interrupt_ldt_clr_x (64 bits) interrupt_diag_x (64 bits) interrupt_mask_x (64 bits) interrupt_ldt_x (64 bits) ht interrupt decode logic (expands to set one of the 128 bits) in terrupt_source_status_x (64 bits) system sources map registers in o 0 4 interrupt_status_0_x (64 bits) int 0 int_trace_trigger_x interrupt_ldt_set (64 bits) (same location for all mappers) 64 64 64 64 64 64 64 64 o 1 interrupt_status_1_x (64 bits) int 1 64 64 o 2 interrupt_status_2_x (64 bits) int 2 64 64 o 3 interrupt_status_3_x (64 bits) int 3 64 64 o 4 interrupt_status_4_x (64 bits) int 4 64 64 o 5 interrupt_status_5_x (64 bits) int 5 64 64 o 6 interrupt_status_6_x (64 bits) nmi 64 64 interrupt_map_0_x (3 bits) ... interrupt_map_63_x (3 bits) each input is linked to one output o 7 interrupt_status_7_x (64 bits) dint 64 64 trace_seq_debug_cpu_x bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 52 section 4: system control and debug unit document 1250_1125-um100-r the main interrupt registers are all 64 bits wide: table 21: interrupt registers name description interrupt_diag _0 - 00_1002_0010 _1 - 00_1002_2010 setting a bit in this register raises the corresponding interrupt. software must clear the bit to remove the interrupt. this register is intended for diagnostics only. interrupt_ldt_set 00_1002_0048 this write only register is written with a hypertransport interrupt message and will decode it into setting a single bit in either the interrupt_ldt or mailbox register, and thus an interrupt will be raised. interrupt_ldt _0 - 00_1002_0018 _1 - 00_1002_2018 the hypertransport interrupt controller will set the bit corresponding to the interrupt vector number for vectors in the range 0-63. the cpu can read this register to find which hypertransport interrupts have been posted. interrupt_ldt_clr _0 - 00_1002_0020 _1 - 00_1002_2020 this is not a register. writing a one to a bit in this location clears the corresponding bit in the interrupt_ldt register. interrupt_mask _0 - 00_1002_0028 _1 - 00_1002_2028 setting a bit in this register masks the corresponding interrupt. all bits in this register are set at reset, masking out all interrupts. interrupt_status_n n=0-7 _0 - 00_1002_0100..138 _1 - 00_1002_2100..138 read only. there is a status register for each of the outputs from the mapper. a bit will be set only if the corresponding source is interrupting, is not masked and is mapped to this output. interrupt_source_status _0 - 00_1002_0040 _1 - 00_1002_2040 read only. a bit will be set if the corresponding source is interrupting regardless of the state of the interrupt mask. interrupt_trace _0 - 00_1002_0038 _1 - 00_1002_2038 setting a bit in this register allows the interrupt to trigger the trace unit. interrupt_map0 ... interrupt_map63 _0 - 00_1002_0200..3f8 _1 - 00_1002_2200..3f8 there are 64 interrupt mapper registers. each is 3 bits wide and encodes the mapping from the interrupt number given in tab l e 2 2 onto the cpu interrupt lines as described in ta bl e 1 8 . table 22: interrupt sources number name description method to clear 0 watchdog_timer_int_0 watchdog timer 0 timeout interrupt is raised on first timeout of the timer (the second will reset the machine). it is cleared by writing to the timer configuration register. see section: ?watchdog timers? on page 57 . 1 watchdog_timer_int_1 watchdog timer 1 timeout interrupt is raised on first timeout of the timer (the second will reset the machine). it is cleared by writing to the timer configuration register. see section: ?watchdog timers? on page 57 . 2 timer_int_0 general timer 0 interrupts when timer reaches zero, cleared by a write to the timer configuration register. see section: ?general timers? on page 58 . 3 timer_int_1 general timer 1 interrupts when timer reaches zero, cleared by a write to the timer configuration register. see section: ?general timers? on page 58 . 4 timer_int_2 general timer 2 interrupts when timer reaches zero, cleared by a write to the timer configuration register. see section: ?general timers? on page 58 . user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 53 5 timer_int_3 general timer 3 interrupts when timer reaches zero, cleared by a write to the timer configuration register. see section: ?general timers? on page 58 . 6 smb_int_0 smbus 0 interrupt interrupts when transfer completes or an error is signalled by smbus unit 0. cleared by reading status register or writing the error bit. see section: ?programming model? on page 409 . 7 smb_int_1 smbus 1 interrupt interrupts when transfer completes or an error is signalled by smbus unit 1. cleared by reading status register or writing the error bit. see section: ?programming model? on page 409 . 8 uart_int_0 uart channel a interrupt interrupts from uart channel a are merged into this one signal, cleared as defined in section: ?interrupts? on page 324 . 9 uart_int_1 uart channel b interrupt interrupts from uart channel b are merged into this one signal, cleared as defined in section: ?interrupts? on page 324 . 10 ser_int_0 synch serial 0 interrupt dma status and errors from the synchronous serial interface are combined into this interrupt, cleared as defined in section: ?synchronous serial interrupts? on page 351 . 11 ser_int_1 synch serial 1 interrupt dma status and errors from the synchronous serial interface are combined into this interrupt, cleared as defined in section: ?synchronous serial interrupts? on page 351 . 12 pcmcia_int pcmcia controller interrupt there are three sources for interrupt from the pcmcia controller, they are cleared by reading the pcmcia_status register as described in section: ?using the pcmcia card? on page 389 . 13 addr_trap_int address trap interrupt raised by any of the address traps counting from 1 to 0. cleared by reading the addr_trap_reg . see section: ?address trapping? on page 67 . 14 perf_cnt_int system performance counter interrupt raised by any of the system performance counters reaching its maximum count. cleared by clearing the counters. 15 trace_freeze_int trace buffer frozen interrupt this interrupt is raised when the trace buffer is frozen, and cleared when the buffer is reset. see section: ?trigger sequences? on page 73 . 16 bad_ecc_int uncorrectable ecc error or bus error this interrupt is raised by the bus watcher when a zbbus data transfer is marked as having an uncorrectable ecc error or some other form of fatal error. this indicates an uncorrectable ecc from either the l2 cache or memory, or a fatal error from one of the other agents. it is cleared by a read of the bus_err_status register. 17 cor_ecc_int correctable ecc error this interrupt is raised by the bus watcher when a zbbus data transfer is marked as having a corrected ecc error. this indicates an corrected ecc from either the l2 cache or memory, or a non-fatal error from one of the other agents. it is cleared by a read of the bus_err_status register. 18 io_bus_int generic bus error: illegal address, timeout waiting ack, parity error raised by an error condition in the generic bus logic. the access that caused the error is logged (see the generic bus description). the interrupt is cleared by reading the io_int_status register. table 22: interrupt sources (cont.) number name description method to clear bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 54 section 4: system control and debug unit document 1250_1125-um100-r 19 mac_0_int mac 0 interrupt raised by an error in the mac or when any of the four dma channels need service. cleared by reading the mac_status_0 register or servicing the dma interrupt. 20 mac_1_int mac 1 interrupt raised by an error in the mac or when any of the four dma channels need service. cleared by reading the mac_status_1 register or servicing the dma interrupt. 21 mac_2_int mac 2 interrupt raised by an error in the mac or when any of the four dma channels need service. cleared by reading the mac_status_2 register or servicing the dma interrupt. 22 dm_ch_0_int data mover channel 0 interrupt raised at the end of data transfer in channel 0 if a data mover descriptor has the interrupt bit set. cleared by reading the dm_dscr_base_0 register. 23 dm_ch_1_int data mover channel 1 interrupt raised at the end of data transfer in channel 1 if a data mover descriptor has the interrupt bit set. cleared by reading the dm_dscr_base_1 register. 24 dm_ch_2_int data mover channel 2 interrupt raised at the end of data transfer in channel 2 if a data mover descriptor has the interrupt bit set. cleared by reading the dm_dscr_base_2 register. 25 dm_ch_3_int data mover channel 3 interrupt raised at the end of data transfer in channel 3 if a data mover descriptor has the interrupt bit set. cleared by reading the dm_dscr_base_3 register. 26 mbox_int_0 mailbox bits [63:48] non zero interrupts when another cpu or the hypertransport interrupt controller sets any bit, cleared when the cpu clears all the bits. 27 mbox_int_1 mailbox bits [47:32] non zero interrupts when another cpu or the hypertransport interrupt controller sets any bit, cleared when the cpu clears all the bits. 28 mbox_int_2 mailbox bits [31:16] non zero interrupts when another cpu or the hypertransport interrupt controller sets any bit, cleared when the cpu clears all the bits. 29 mbox_int_3 mailbox bits [15:0] non zero interrupts when another cpu or the hypertransport interrupt controller sets any bit, cleared when the cpu clears all the bits. 30 cycle_cp0_int zbbus cycle count match 0 interrupts when the zbbus cycle count matches compare register 0. cleared by any write to zbbus_cycle_cp0 . 31 cycle_cp1_int zbbus cycle count match 1 interrupts when the zbbus cycle count matches compare register 1. cleared by any write to zbbus_cycle_cp1 . 32 gpio_int_0 gpio pin 0 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 33 gpio_int_1 gpio pin 1 interrupt 34 gpio_int_2 gpio pin 2 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 35 gpio_int_3 gpio pin 3 interrupt table 22: interrupt sources (cont.) number name description method to clear user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 55 36 gpio_int_4 gpio pin 4 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 37 gpio_int_5 gpio pin 5 interrupt 38 gpio_int_6 gpio pin 6 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 39 gpio_int_7 gpio pin 7 interrupt 40 gpio_int_8 gpio pin 8 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 41 gpio_int_9 gpio pin 9 interrupt 42 gpio_int_10 gpio pin 10 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 43 gpio_int_11 gpio pin 11 interrupt 44 gpio_int_12 gpio pin 12 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 45 gpio_int_13 gpio pin 13 interrupt 46 gpio_int_14 gpio pin 14 interrupt interrupts when external source raises an interrupt. if level sensitive, the external source must clear the interrupt. if edge triggered the gpio_clr_edge register must be written to clear the interrupt. generation of these two interrupts may be disabled in the gpio_int_type register to free these vectors for use by hypertransport interrupts. 47 gpio_int_15 gpio pin 15 interrupt 48 ldt_fatal_int hypertransport fatal error interrupt this bit is set when a fatal error is detected by the hypertransport interface. the hypertransport error control register is used to classify the hypertransport errors. software must clear all fatal error status bits to clear the interrupt. 49 ldt_nonfatal_int hypertransport nonfatal error interrupt this bit is set when a non fatal error is detected by the hypertransport interface. the hypertransport error control register is used to classify the hypertransport errors. software must clear all nonfatal error status bits to clear the interrupt. 50 ldt_smi hypertransport signaled smi this bit is reserved in the system interrupt register, and comes only from the ldt_interrupt register. this bit is set when an smi interrupt packet directed to this cpu had been received from the hypertransport bus. this bit is cleared using the interrupt clear register. hypertransport interrupts are directed, so the source for this bit differs for each interrupt controller. table 22: interrupt sources (cont.) number name description method to clear bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 56 section 4: system control and debug unit document 1250_1125-um100-r 51 ldt_nmi hypertransport signaled nmi this bit is reserved in the system interrupt register, and comes only from the ldt_interrupt register. this bit is set when an nmi interrupt packet directed to this cpu had been received from the hypertransport bus. this bit is cleared using the interrupt clear register. hypertransport interrupts are directed, so the source for this bit differs for each interrupt controller. 52 ldt_init hypertransport signaled init this bit is reserved in the system interrupt register, and comes only from the ldt_interrupt register. this bit is set when an init interrupt packet directed to this cpu had been received from the hypertransport bus. this bit is cleared using the interrupt clear register. hypertransport interrupts are directed, so the source for this bit differs for each interrupt controller. 53 ldt_startup hypertransport signaled startup this bit is reserved in the system interrupt register, and comes only from the ldt_interrupt register. this bit is set when a startup interrupt packet directed to this cpu had been received from the hypertransport bus. this bit is cleared using the interrupt clear register. hypertransport interrupts are directed, so the source for this bit differs for each interrupt controller. 54 ldt_ext_int hypertransport signaled extint this bit is reserved in the system interrupt register, and comes only from the ldt_interrupt register. this bit is set when an extint interrupt packet directed to this cpu had been received from the hypertransport bus. this bit is cleared using the interrupt clear register. hypertransport interrupts are directed, so the source for this bit differs for each interrupt controller. 55 pci_error_int pci error interrupt this bit is set when an error is seen on the pci bus. it can be caused by pci parity errors, target-abort, master-abort, timeout transfer abort or a serious system error signalled on the serr pin. the cause can be read from the pci interface configuration space (bus=0, dev=0, function=0) status register (bits 8, 11, 12, 13 and 14), and the pci additional status and control register. software must clear all the error status bits to clear the interrupt. 56 pci_inta_int pci interrupt a this bit is set when an interrupt is signalled on the pci inta line. 57 pci_intb_int pci interrupt b this bit is set when an interrupt is signalled on the pci intb line. 58 pci_intc_int pci interrupt c this bit is set when an interrupt is signalled on the pci intc line. 59 pci_intd_int pci interrupt d this bit is set when an interrupt is signalled on the pci intd line. 60 spare_int spare interrupt there is no system interrupt matching this bit. it can be used for vectored hypertransport interrupts. 61 mac_0_ch1_int mac 0 channel 1 interrupt raised when channel 1 transmit or receive dma engine needs service. cleared by any read to mac_status1_0 . 62 mac_1_ch1_int mac 1 channel 1 interrupt raised when channel 1 transmit or receive dma engine needs service. cleared by any read to mac_status1_1 . 63 mac_2_ch1_int mac 2 channel 1 interrupt raised when channel 1 transmit or receive dma engine needs service. cleared by any read to mac_status1_2 . table 22: interrupt sources (cont.) number name description method to clear user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 57 t imers there are two types of timers on the part: watchdog and general. watchdog timers can be used to detect the liveliness of the system and will cause a full system reset if software does not prove its correct operation by regularly resetting the timer. general timers are available for any use and can be set to generate a regular interrupt or act as one shot timers. both sorts of timer count in 1 us steps and have a maximum timeout of over 8s. the timers all have a similar programming interface. each timer module consists of an initial count register, a down counter which is loaded with the initial count and then decrements, and a configuration register. the initial count register should only be written while the timer is disabled. whenever the timer enable bit in the control register is written with a 1 the down counter is loaded with the initial count and begins decrementing. when the counter reaches zero an interrupt is raised. w atchdog t imers the watchdog timers have a 23 bit counter and are clocked by a 1 mhz clock derived from the 100 mhz reference clock. this allows a maximum count of 8388608, giving the maximum timeout of 8.3888608 s. a watchdog timer is normally not permitted to timeout. system software should regularly re-enable the timer by writing a 1 to the enable bit in the configuration register. this will restore the count to the initial count and force the counter to restart decrementing from there. if the timer is permitted to reach zero then on the next clock tick an interrupt will be raised, the counter will reload from the initial count and decrementing will continue. this interrupt warns the system software that it has not been re-enabling the timer. the interrupt will be cleared by any write to the configuration register. if the timer times out for a second time (i.e. before the interrupt has been cleared) the default behavior of the watchdog is to signal the system controller to perform a full reset of the part (and any external devices that take re set from the resetout_l, ldt_reset_l/ht_reset_l or pci p_rst_l signals). once the watchdog has signalled a reset it will be disabled. there are two watchdog timers on the part. they are identical other than using different registers (distinguished by appending register names with _0 and _1 ) and different interrupt lines. on the bcm1250 this allows the liveliness of each processor to be separately monitored. this will be of benefit when the two cpus are running loosely coupled (for example when one runs a real-time task and the other does general system control). the interrupt mapper can be used to route a timeout interrupt from either watchdog to either or both processors (this allows each of them to monitor the other). the watchdog can be configured to do a more selective reset when it times out for the second time. it can send an sb_softres (as described in section: ?system control? on page 41 ), reset just one cpu, or (on the bcm1250) reset both cpus but no peripherals. care must be taken if this is done, the reset software will need to probe for devices that are hung or in inconsistent states. the behavior should only be changed from the default in high availability systems or in some cases where the two cpus are running distinct operating systems. care must be taken in systems that boot from an smbus eeprom, none of the selective resets set the smbus channel to boot operation if it has been returned to normal operation. an additional problem with resetting only a cpu is that it will immediately be removed from the coherence machinery. it is possible that the cpu had just been detected as exclusive owner of a cache block and was in the process of providing it when reset. since the data will never be supplied the zbbus transaction will never be terminated and the requester will hang. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 58 section 4: system control and debug unit document 1250_1125-um100-r g eneral t imers the part has four general timers. each has a 23 bit counter and is clocked by a 1 mhz clock derived from the 100 mhz reference clock. this allows a maximum count of 8388608, giving the maximum one-shot timeout of 8.388608 s, and a maximum periodic interrupt every 8.388608 s. the timers can be either set to count down from the initial count to zero and stop, or repeatedly count down. a timer should always be disabled before its operating mode is changed. when the timer is enabled in the one-shot mode the counter is loaded from the initial count register and will decrement to zero. when the count reaches 0, the next clock tick causes an interrupt to be generated and the timer is disabled. the count will remain at 0 until the timer is re-enabled by software. the interrupt is cleared by any write to the configuration register, regardless of whether the timer is kept in the disabled state or enabled. if the timer is re-enabled before its counter reaches 0, its counter is reloaded with the initial count and will restart decrementing. in the second mode, the counter is loaded from the initial count and will decrement to zero. when the counter reaches zero the next clock tick cause an interrupt to be generated and the counter to be reloaded with the initial count and start counting down again. when the counter is in this mode it will not be reloaded if it is re- enabled (but it will if it is disabled and then enabled agai n). the interrupt is cleared by any write to the configuration register, if regular interrupts are requi red this write should re-enable the counter. there is no detection of missed interrupts, once the interrupt has asserted it will only be raised again after it has been cleared and then the counter reaches zero. t imer s pecial c ases if the initial count of any timer (regardless of mode) is set to zero and the timer is enabled then an interrupt will be signalled every clock tick. it is unpredictable if writing the configuration register will cause the interrupt to deassert. it is unpredictable how many ticks a watchdog timer will take to assert reset. if the initial count register is updated or the mode is changed between one-shot and continuous while the counter is enabled the behavior is unpredictable. zb bus c ycle c ount and c ompare there is an additional read only counter that is initialized to zero and increments every zbbus cycle. even in the fastest parts it will take more than 1000 years for the counter to wrap. it can therefore be used to provide a sequence number that is unique and monotonically increasing through the runtime of the system. this is useful for software that needs to assign an order to events. the counter may also be used as a high resolution clock for timing. the read only zbbus_cycle_count register is placed at the start of a 64kb memory range, if additional registers are added in this range they will be read only with no side effects. this range can therefore be safely mapped into user address space. there are two comparison registers which will raise an interrupt when the count matches the comparison value. the interrupt will remain asserted until the compare register is written. note that the interrupt is only raised on equality, so writing the compare register with a value lower than the current count will ensure the interrupt is never raised. since cycle 0 is guaranteed to have passed by the time the cpu executes the first instruction, writing the compare register with zero is always a safe way to clear the interrupt and disable it. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 59 t imer r egisters table 23: watchdog timer initial count registers watchdog_timer_init_cnt_0 - 00_1002_0050 watchdog_timer_init_cnt_1 - 00_1002_0150 bits name default description 22:0 watchdog_timer_init_cnt 23'bx watchdog timer initial count register. sets the watchdog timeout time in microseconds. this register should only be written when the timer is disabled. if written when the timer is enabled the results are unpredictable. 63:23 reserved 41'h0 reserved table 24: watchdog timer current count registers watchdog_timer_cnt_0 - 00_1002_0058 watchdog_timer_cnt_1 - 00_1002_0158 read only bits name default description 22:0 watchdog_timer_cnt 23'bx watchdog timer current count register. when the counter is enabled the count decrements every microsecond. 63:23 reserved 41'h0 reserved table 25: watchdog timer configuration registers watchdog_timer_cfg_0 - 00_1002_0060 watchdog_timer_cfg_1 - 00_1002_0160 write clears interrupt bits name default description 0 watchdog_timer_enable 1'b0 when this bit is written with a 0 the timer will be disabled. when this bit is written with a 1 regardless of its previous state the timer will be loaded from the initial count and start decrementing. 1 reserved 1?b0 reserved 4:2 reset_type 3'b0 this field sets the type of reset that is generated when the watchdog times out for the second time. in most situations the (default) full system reset is the correct behavior, since this will clear all state. xx0: full system reset (default). 001: sb soft reset (full reset retaining system_cfg register value). 011: reset only cpu 0. 101: reset only cpu 1. 111: reset only cpu 0 and cpu 1 (no peripherals). 5 wd_has_reset 1'bx this bit is reserved prior to periph_rev3. on periph_rev3 and later it indicates if the watchdog timer has caused a reset. following power up the value of this bit is unpredictable. whenever this register is written this bit becomes zero. if the watchdog causes a reset this bit is set. 7:6 reserved 2'b0 reserved 63:8 notimp 56?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 60 section 4: system control and debug unit document 1250_1125-um100-r table 26: general timer initial count registers general_timer_init_cnt_0 - 00_1002_0070 general_timer_init_cnt_1 - 00_1002_0078 general_timer_init_cnt_2 - 00_1002_0170 general_timer_init_cnt_3 - 00_1002_0178 bits name default description 22:0 timer_init_cnt 23'bx timer initial count register. this sets the maximum value of the counter, and will be one less than the timeout in microseconds for one-shot mode, and one less than the period in microseconds in continuous mode. this register should only be written when the timer is disabled. if written when the timer is enabled the results are unpredictable. 63:23 reserved 41'h0 reserved table 27: general timer current count registers general_timer_cnt_0 - 00_1002_0080 general_timer_cnt_1 - 00_1002_0088 general_timer_cnt_2 - 00_1002_0180 general_timer_cnt_3 - 00_1002_0188 read only bits name default description 22:0 timer_cnt 23'bx timer current count register. when the timer is running the count decrements every microsecond. 63:23 reserved 41'h0 reserved table 28: general timer configuration registers general_timer_cfg_0 - 00_1002_0090 general_timer_cfg_1 - 00_1002_0098 general_timer_cfg_2 - 00_1002_0190 general_timer_cfg_3 - 00_1002_0198 write clears interrupt bits name default description 0 general_timer_cfg_enable 1'b0 when high, enable the general purpose timer. if the timer is disabled when this bit is written with a 1 the timer will be loaded from the initial count register and will start decrementing. if the timer is enabled when this bit is written with a 1 the timer continues to decrement, but if the general_timer_cfg_mode bit is 0 the counter will also be reloaded with the initial count. if this bit is written with a 0 the timer will stop decrementing. 1 general_timer_cfg_mode 1'b0 when low, the general purpose timer stops at 0. when high, the general purpose timer runs continuously. 7:2 reserved 6'h0 reserved 63:8 notimp 56?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 61 s ystem p erformance c ounters there are four system performance counters. they count system events and interrupt when saturated. all four counters are cleared and/or enabled simultaneously. when one counter saturates, all counters are frozen. thus, the readings across the four counters cover the same interval. the counters are writable; if they are written while active the count will continue from the new value (note that the time from the cpu issuing a store to the counter getting the new value is unpredictable). the counters are all controlled by the perf_cnt_cfg register. this is used to configure the count source for each counter, to enable or disable all the counters and to clear all the counters. the counter clear bit is write only, the counters will all be cleared to zero at the end of the cycle that this bit is written with a 1. if both the enable and clear bits are written with 1 in the same write, t he counters are cleared and will start counting the cycle after the write completes. if any counter reaches its maximum count the counters will all be disabled (the enable bit in the perf_cnt_cfg register is cleared) and the perf_cnt_int interrupt will be raised. the interrupt is removed and all the counters are cleared when the clear bit in the perf_cnt_cfg register is written with a 1. since it takes a cycle to disable the counters there is one additional cycle sampled after one (or more) of the counts reaches ff_ffff_ffff during which the counter may overflow (if its source is still active). there is an additional bit in the performance counters that gets set when they overflow, thus the counter (or counters) that disabled monitoring could have the value ff_ffff_ffff or 100_0000_0000 when the interrupt is seen. table 29: zbbus count register zbbus_cycle_count - 00_1003_0000 read only note 00_1003_0008 - 00_1003_ffff is safe for user space access bits name default description 63:0 count 64'h0 count of zbbus cycles since reset. writes will be ignored. table 30: zbbus count compare registers zbbus_cycle_cp0 - 00_1002_0c00 zbbus_cycle_cp1 - 00_1002_0c08 bits name default description 63:0 compare 64'hffff_ffff _ffff_ffff value is compared to zbbus_cycle_count and the interrupt corresponding to the register is raised when the count is equal to the value. the interrupt is cleared by any write to the compare register. table 31: system performance counter configuration registers perf_cnt_cfg - 00_1002_04c0 bits name default description 7:0 counter 0 source 8'b0 sets the source for counter 0. 15:8 counter 1 source 8'b0 sets the source for counter 1. 23:16 counter 2 source 8'b0 sets the source for counter 2. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 62 section 4: system control and debug unit document 1250_1125-um100-r 31:24 counter 3 source 8'b0 sets the source for counter 3. 32 clear 1'b0 if this bit is set in a write to the register the counters will be reset, the bit self-clears and always reads as zero. 33 enable 1'b0 set to enable the counters, clear to stop them. cleared automatically by any counter reaching its maximum count. 63:34 reserved 30'b0 reserved table 31: system performance counter configuration registers (cont.) perf_cnt_cfg - 00_1002_04c0 bits name default description table 32: system performance counters perf_cnt_0 - 00_1002_04d0 perf_cnt_1 - 00_1002_04d8 perf_cnt_2 - 00_1002_04e0 perf_cnt_3 - 00_1002_04e8 bits name default description 39:0 count 40'bx performance counter. 40 oflow 1'b0 this bit is set if the counter overflows. 63:41 reserved 23'b0 reserved table 33: system performance counter sources value condition counted 00 no count. 01 bus cycles are counted. the counter is incremented each zbbus clock cycle (half the cpu clock). 02 bus cycles used. the counter is incremented every cycle the address portion of zbbus is used. 03 address bus cycles waiting grant. the counter is incremented every cycle some agent loses arbitration for the address bus (i.e. there are two or more requesters in arbitration). 04 address bus cycles arbitrated but not used. the counter is incremented every time the address bus is granted but the agent drives a nop command. 05 address match 0 count - counts each bus address cycle that matches the address trap comparator. the occurrence counter (that is used to determine if the address trap should interrupt) is ignored, the performance counter will increase every cycle there is a hit in the trap. 06 address match 1 count. (see comments for address match 0.) 07 address match 2 count. (see comments for address match 0.) 08 address match 3 count. (see comments for address match 0.) 09 data bus cycles waiting grant. the counter is incremented every cycle some agent loses arbitration for the data bus (i.e. there are two or more requesters in arbitration). 0a data bus cycles arbitrated but not used. the counter is incremented every time the data bus is granted but the agent drives a nop command. 0b cpu0 eden. the counter is incremented every time cpu 0 asserts its external debug event notification (eden) signal. this can be asserted by software, or watchpoint register hits. 0c cpu1 eden. the counter is incremented every time cpu 1 asserts its external debug event notification (eden) signal. this can be asserted by software, or watchpoint register hits. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 63 0d interrupt request cycles. the counter is incremented ever y bus cycle the int_trace_trigger_x output of the interrupt mapper is asserted (see figure 10 on page 51 ). this records the time taken from the interrupt assertion to software clearing the interrupt condition. if a single interrupt source is selected and the count is read at the start of the interrupt service routine and cleared when the interrupt is cleared, software will be able to track the interrupt service time. counters 0 and 1 count based on int_trace_trigger_0, counters 2 and 3 count based on int_trace_trigger_1. 0e interrupt request count. the counter is incremented every time the int_trace_trigger_x output of the interrupt mapper changes from not asserted to asserted (see figure 10 on page 51 ). this records the number of interrupts, and can be used with the interrupt request cycles count to determine the average number of cycles between an interrupt being raised and cleared. counters 0 and 1 count based on int_trace_trigger_0, counters 2 and 3 count based on int_trace_trigger_1. 0f reserved 1n agent n request count - counts number of cycles that agent n requested the bus. 2n agent n grant delay count - counts the total sum of cycles between agent n requesting the bus, and agent n receiving grant on the bus. 30 memory channel 0 read accesses. counts the number of reads to memory. 31 memory channel 0 write accesses. counts the number of writes to memory. 32 memory channel 0 turnarounds. counts the number of times the controller changes from read-to-write or write- to-read. 33 memory channel 0 page hits. counts the number of page hits in the memory controller. 34 memory channel 0 controller wait cycles. counts the number of cycles the controller is waiting for precharge and chip select overhead. 35 memory channel 1 read accesses. counts the number of reads to memory. 36 memory channel 1 write accesses. counts the number of writes to memory. 37 memory channel 1 turnarounds. counts the number of times the controller changes from read-to-write or write- to-read. 38 memory channel 1 page hits. counts the number of page hits in the memory controller. 39 memory channel 1 controller wait cycles. counts the number of cycles the controller is waiting for precharge and chip select overhead. 3a l2 read requests. counts the number of read requests to the l2 cache. 3b l2 read misses. counts the number of read requests that missed the l2 cache. 3c l2 write requests. counts the number of write requests to the l2 cache. 3d l2 write misses. counts the number of write requests that missed the l2 cache. 3e l2 evicts. counts the number of lines evicted from the l2 cache. 3f-ff reserved table 33: system performance counter sources (cont.) value condition counted bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 64 section 4: system control and debug unit document 1250_1125-um100-r b us w atcher the bus watcher monitors zbbus data transfers, detecting error reports. corrected ecc errors from memory and the l2 cache are counted. uncorrectable ecc errors are counted and logged. the bus watcher will raise an interrupt when it detects an error. when a data bus transaction is made with an error code the bus watcher logs the transaction (in the bus_err_data registers and the the bus_err_status register), and increments the appropriate counter. if the error was an unrecoverable one (uncorrectable ecc error or bus error or fatal error) the log is frozen until the bus_err_status register is read. (the unrecoverable errors are dcode=4-7). the bus watcher contains the following counters: each counter is 8 bits, and saturates at 8'hff. softwar e may write any value into the counters, a counter is cleared by writing zero to it. the counter s are collected into two 32-bit registers, bus_l2_errors for the l2 cache counts and bus_mem_io_errors for the other counts. these registers should only be written with 32- bit or 64-bit writes, using smaller will result in the value of some of the counters becoming unpredictable. in addition to the type of error the bus_err_status register records information about the transaction that encountered the error. the upper four bits of the transaction id can be used to determine which of the zbbus agents initiated the transaction that resulted in an error, see table 1 on page 20 for the number of each agent. in some cases the lower six bits of the transaction id can be decoded to get more information about the request, see table51onpage81 . the responder id gives the number of the agent that reported the error. the data that was returned with the error code is also captured, but in many cases it will be of unpredictable value. note that when a bus error or fatal error is returned to a cpu it will take a bus error exception and when an uncorrectable ecc error is returned it will take a cache error exception. these exceptions are taken with a higher priority than the interrupt from the bus watcher, or any interrupt raised by the source of the error. dma engines that receive any of these errors will stop and report the error in some way. if any of these errors are returned to the pci or hypertransport interfaces they will be converted into the apropriate error returned on the interface and flags will be set in the csrs to indicate this has been done. thus an error is likely to be reported several times, ensuring that processing is never done based on corrupted data. the correctable table 34: bus watcher counters name use bus_l2_cor_d_ecc counts correctable l2 cache data ecc errors. the cor_ecc_int interrupt is raised every time this counter increments. bus_l2_bad_d_ecc counts uncorrectable l2 cache data ecc errors. the bad_ecc_int interrupt is raised every time this counter increments. bus_l2_cor_t_ecc counts correctable l2 cache tag ecc errors. the cor_ecc_int interrupt is raised every time this counter increments. bus_l2_bad_t_ecc counts uncorrectable l2 cache tag ecc errors. the bad_ecc_int interrupt is raised every time this counter increments. bus_mem_cor_d_ecc counts correctable memory data ecc errors. the cor_ecc_int interrupt is raised every time this counter increments. bus_mem_bad_d_ecc counts uncorrectable memory data ecc errors. the bad_ecc_int interrupt is raised every time this counter increments. bus_error counts fatal errors and bus errors. the bad_ecc_int interrupt is raised every time this counter increments. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 65 errors do not raise exceptions or cause the dma engines to stop, so the bus watcher interrupt is likely to be the only way they are reported. table 35: bus watcher error status register bus_err_status - 00_1002_0880 read only, read will clear all fields and the cor_ecc_int and bad_ecc_int interrupts bits name default description 7:0 reserved 8'b0 reserved 17:8 tid 10'b0 transfer id that had error code. top 4 bits indicate the initiator of the transfer, see table 1 on page 20 for the mapping. low 6 bits may give more details on the what within the agent caused the transaction, see table51onpage81 . 21:18 rid 4'b0 responder id identifies the agent that reported the error. see table 1 on page 20 . 24:22 dcode 3'b0 data transfer error code. see table 6 on page 24 . 29:25 reserved 5'b0 reserved 30 mult_errors 1'b0 set to indicate multiple errors. the first fatal one, or the most recent non- fatal one is logged (all were counted). 31 reserved 1'b1 reserved. reads as 1. 63:32 notimp 32?bx not implemented. table 36: bus watcher error status debug register bus_err_status_debug - 00_1002_08d0 read only bits name default description 63:0 value 64'hx this register contains the same information as the bus_err_status register, but reads do not have any side effects. table 37: bus watcher error data registers bus_err_data_0 - 00_1002_08a0 bus_err_data_1 - 00_1002_08a8 bus_err_data_2 - 00_1002_08b0 bus_err_data_3 - 00_1002_08b8 read only bits name default description 63:0 data 64'hx data from error transaction. the register number is address bits [4:3]. register _0 contains zbbus bits 255:192 register _1 contains zbbus bits 191:128 register _2 contains zbbus bits 127:64 register _3 contains zbbus bits 63:0 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 66 section 4: system control and debug unit document 1250_1125-um100-r table 38: bus watcher l2 ecc counter register bus_l2_errors - 00_1002_08c0 should only be written with 32-bit or 64-bit write bits name default description 7:0 l2_cor_d_ecc 8'b0 count of correctable l2 cache data errors, saturates at 8'hff, write the register with zero to clear the count. 15:8 l2_bad_d_ecc 8'b0 count of uncorrectable l2 cache data errors, saturates at 8'hff, write the register with zero to clear the count. 23:16 l2_cor_t_ecc 8'b0 count of correctable l2 tag errors, saturates at 8'hff, write the register with zero to clear the count. 31:24 l2_bad_t_ecc 8'b0 count of uncorrectable l2 tag errors, saturates at 8'hff, write the register with zero to clear the count. 63:32 notimp 32?bx not implemented. table 39: bus watcher memory and i/o error counter register bus_mem_io_errors - 00_1002_08c8 should only be written with 32-bit or 64-bit write bits name default description 7:0 mem_cor_d_ecc 8'b0 count of correctable memory data errors, saturates at 8'hff, write the register with zero to clear the count. 15:8 mem_bad_d_ecc 8'b0 count of uncorrectable memory data errors, saturates at 8'hff, write the register with zero to clear the count. 23:16 bus_error 8'b0 count of bus errors and fatal bus errors, saturates at 8'hff, write the register with zero to clear the count. 31:24 reserved 8'b0 reserved 63:32 notimp 32?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 67 a ddress t rapping there are four address traps in the scd. an interrupt is raised by any access that falls within the address range specified by a trap. hits to a trap can also be used to trigger the performance counters and trace unit. the address traps are mainly used as a debugging aid, but they can also be used to detect (but not prevent) illegal accesses in the event of a system failure. each address trap has the same interface consisting of a set of registers. the register names described should have _0 , _1 , _2 , or _3 appended to indicate which trap is being used. a 40 bit upper address register addr_trap_up sets the top physical address in the trapping range. an address must be less than or equal to this value to be part of the range. a 40 bit lower address register addr_trap_down sets the base physical address in the trapping range. an address must be greater than or equal to this value to be part of the range. the fields in the addr_trap_cfg register are used to make the trap more selective than just based on an address range. a two bit access_type field selects if the trap is active for read, write or all accesses. the source_id field contains a zbbus source id that is comp ared at the same time as the address. flags determine if the trap is hit when the access is inside or outside the address range, and if the source id must match or differ. each trap has a 3 bit occurrence counter in the addr_trap_cfg register that counts down every time the trap condition is hit. once the occurrence counter is zero it will stick at zero and not continue to decrement. a simple trap ignores the source information. it is setup by programming the upper and lower address registers to set the range, then writing the configuration register with the access type to trap on, and a greater than 0 occurrence count. any access of the selected type with an address greater than or equal to the lower register and less than or equal to the upper register matches the range. thus to trap on a specific address the upper and lower addresses are set to be the same. when an access matches and the occurrence counter is greater than zero, the counter will decrement. provided the address trap interrupt is clear, any address trap match will log the address that matched in the addr_trap_reg and the trap number in the addr_trap_index . the first time an occurrence counter from any trap decrements from 1 to 0 the address trap interrupt is raised, both signalling the event and preventing the log registers from being overwritten. further trap matches will continue to decrement their counters, but will otherwise be ignored until the interrupt is cleared by a read of the addr_trap_reg . the cpu should read the addr_trap_index before the addr_trap_reg to ensure a consistent result. more complex traps can be made by inverting the output of the range match (the trap is only hit by addresses outside the range) and considering the source of the access in addition to the address range. the source id that is provided on the zbbus by the initiator of the transa ction (as the transaction id bits a_id[9:6]) is used in the comparison. there are four forms of complex trap: 1 address match, source match. this is used to detect a particular agent accessing a particular memory range. 2 address differs, source match. this will detect an access by a device outside of the range of addresses that it is expected to use. 3 address match, source differs. if a region of memory is reserved for use by a single agent (for example cpu 1) this will detect an access to the region by any other agent. (note that this provides detection only, not prevention). 4 address differs, source differs. if all of the memory can be used by one agent (for example the master cpu), but all other agents are confined to a particular region, this will detect illegal accesses by other agents. it could be used if only the master cpu were given access to i/o addresses and other agents are confined to memory. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 68 section 4: system control and debug unit document 1250_1125-um100-r the complex trap can also use the cacheability attributes to determine if the request matches the trap. the trap can be set to trigger if the access is uncached, cacheable coherent or cacheable non-coherent. it can also only trigger for requests that do not match the expected cacheability. this can aid debugging by detecting accesses to areas of the address space that are made with the wrong attribute. the complex traps use the occurrence counter in the same way as simple traps. when an access hits the trap (ignoring the value of the occurrence counter) a signal is provided to the trace trigger logic (described in section: ?trigger events? on page 70 ) and to the performance counter selector ( section: ?system performance counters? on page 61 ). table 40: address trap trigger index register addr_trap_index - 00_1002_00b0 read only bits name default description 3:0 addr_trap_index 4'b0 trap that triggered the interrupt. 7:4 reserved 4'h0 reserved table 41: address trap trigger debug register addr_trap_reg_debug - 00_1002_0460 read only bits name default description 63:0 value 64'hx this register contains the same information as the addr_trap_reg register, but reads do not have any side effects. table 42: address trap trigger address register addr_trap_reg - 00_1002_00b8 read only, read clears interrupt bits name default description 4:0 addr_trap 5'h0 always reads as zero. 39:5 addr_trap 35'h0 address that triggered the interrupt. 63:40 reserved 24'h0 reserved table 43: address trap ra nge top address registers addr_trap_up_0 - 00_1002_0400 addr_trap_up_1 - 00_1002_0408 addr_trap_up_2 - 00_1002_0410 addr_trap_up_3 - 00_1002_0418 bits name default description 39:0 addr_trap_up 40'hx top address in range to compare. 63:40 reserved 24'h0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 69 table 44: address trap range base address registers addr_trap_down_0 - 00_1002_0420 addr_trap_down_1 - 00_1002_0428 addr_trap_down_2 - 00_1002_0430 addr_trap_down_3 - 00_1002_0438 bits name default description 39:0 addr_trap_down 40'hx base address in range to compare. 63:40 reserved 24'h0 reserved table 45: address trap configuration registers addr_trap_cfg_0 - 00_1002_0440 addr_trap_cfg_1 - 00_1002_0448 addr_trap_cfg_2 - 00_1002_0450 addr_trap_cfg_3 - 00_1002_0458 bits name default description 2:0 addr_trap_cnt 3'b0 address trap count. decrements on address range matches, sticking at 0. the 1 to 0 transition will trigger an interrupt. note that this count is not applied when an address trap hit is used to trigger a trace event. 3 addr_trap_access_type 1'b0 when low, indicates read trap. when high, indicates write trap. 4 all_accesses 1'b0 ignore the state of bit 3, and trap on any matching access. 5addr_inv 1'b0 these bits enable complex matches by allowing the source agent of the transaction to be compared, and inverting the sense of both address and source comparisons. useful values are: x00: trap for all sources if address is in the range. x01:trap for all sources if address is not in the range. 010:trap if top 4 bits of tid matches source and address is in the range. 011: trap if top 4 bits of tid matches source and address is outside the range. 110: trap if top 4 bits of tid does not match source and address is in the range. 111: trap if top 4 bits of tid does not match source and address is outside the range. 6use_source 1'b0 7source_inv 1'b0 11:8 source_id 4'b0 agent id to use in source comparison. 13:12 cattr 2?b00 these bits enable complex matches by allowing the cacheability attribute of the transaction to be compared, and having the trap match if the access has or does not have the expected attribute. useful values are: x00: ignore the cacheability attribute. 001: trap if uncachable. 010: trap if cacheable non-coherent. 011: trap if cacheable coherent. 101: trap if cacheable (not uncacheable). 110: trap if not cacheable non-coherent. 111: trap if not cacheable coherent. the cacheability is decoded from the a_l1ca signal: 2?b00: cacheable non-coherent. 2?b01: cacheable coherent. 2?b1x: uncacheable. 14 cattr_inv 1?b0 63:15 notimp 49?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 70 section 4: system control and debug unit document 1250_1125-um100-r t race u nit the trace unit allows zbbus activity to be non-intrusively traced. there is a 12kb buffer into which a trace of the address or data activity on the bus can be written. the trace may be read out either by a cpu or through the jtag interface. triggers and filters allow control of the activity that is traced. the trace buffer contains 256 entries, each of 384 bits. each entry can hold either three address/control bundles (each 128 bits) or one full bundle containing address/control information (128 bits) and a databus snapshot (256 bits). when a full bundle is captured it will always start a new buffer entry, marking any unused address/control slots in the previous entry empty. the trace buffer is reset either by software or using the jtag interface. a trigger is used to start collection of a trace. once collection is enabled, filters are applied to every bus cycle which select not sampling, taking an address sample or taking a complete sample that cycle (the filter can also select that every cycle is recorded). the buffer pointer will advance modulo 256, thus the trace ram is used as a circular buffer leaving the latest 256 entries available. a trigger can stop collection, the trace buffer pointer maintains its value and will continue filling the buffer when a start trigger is again encountered. a trigger can also freeze collection. following this, collection cannot be restarted until the trace buffer is reset. an option can be set to freeze collection the first time the buffer fills, this turns the circular buffer into a linear buffer. the same mechanism is used to construct both triggers and filters, they only differ in the flags that are set in the control register. there are two components: events and sequences. a trigger event is signalled when the cycle on the zbbus (or some other system state) matches a condition. up to four events are concatenated to make a sequence. the sequence also includes an action, which is one of the trace buffer commands (start, stop or freeze) and an indication if the trace buffer should record information from the zbbus cycle that is in progress as the sequence completes. when all the events in the sequence have been signalled sequentially the sequence is complete and the action associated with the sequence will take place. t rigger e vents a trigger event is specified as a conditional match on the zbbus address phase signals, or a match on zbbus data phase signals, or the external debug pin being asserted, or a cpu interrupt being raised. there are eight trigger events (event0 - event7), all identical. the address phase match consists of three parts, all of which must be true for the trigger to happen: 1 true if the req_id_match bit is set and the transaction id source on the bus matches the req_id field. always true if the req_id_match bit is clear. 2 true if the addr_match0 bit is set and the address on the bus matches the address trap0 range, or the addr_match1 bit is set and the address on the bus matches the address trap1 range, or the addr_match2 bit is set and the address on the bus matches the address trap2 range, or the addr_match3 bit is set and the address on the bus matches the address trap3 range. always true if none of the addr_match bits are set. the complex (source and cache attribute) address trap match is used to determine a hit, but the trigger does not use the count in the address trap. 3 true if the read bit is set and the bus command is read_shd or read_exc, or the write bit is set and the command is write, write and invalidate, or invalidate. note that having both read and write bits clear disables the address section of the trigger. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 71 the event is triggered by the data phase if the data_id_match bit is set and the top four bits of the transaction id on the data bus (which identify the agent that initiated the transfer) match the data_id field, or the resp_id_match bit is set and the responder id (which provided the data) matches the resp_id field. however, if both data_id_match and resp_id_match bits are set then both ids have to match for the event to trigger. a cpu interrupt can trigger the event. each interrupt mapper contains an interrupt trace mask register. bits are set in this register to indicate that when the corresponding interrupt is raised the event should be triggered. the trace event will trigger when the int_trace_trigger output (see figure 10 on page 51 ) of either interrupt mapper is asserted. this can be used to start tracing when the cpu gets an interrupt from the device being studied. the trigger is edge sensitive and only happens on the change from neither int_trace_trigger outputs being asserted to at least one being asserted. the trigger will not happen again until after the trace outputs from both mappers have cleared. an external device can trigger an event by pulling the debug_l pin low. debug_l is a bidirectional open collector signal and must have an external pull-up to 3.3v. the scd can signal the completion of a trigger event sequence by pulling the signal low for 10 zbbus cycles (see section: ?trigger sequences? on page 73 ). the state of the debug_l signal is ignored during the 10 cycles that the scd is pulling it low and for 5 zbbus cycles after the scd stops driving, so an event will not be triggered by the scd signalling a sequence completion. the trigger is edge sensitive, it will happen once when debug_l changes from high to low and will not happen again until debug_l has returned high. expressing the event trigger in pseudo-code: if (( // address section ( ((trace_event_n[15:12] == zb_req_id) | ~trace_event_n[4]) & ( (trace_event_n[0] & addr_match0) | (trace_event_n[1] & addr_match1) | (trace_event_n[2] & addr_match2) | (trace_event_n[3] & addr_match3) | (trace_event_n[3:0] == 4'h0) ) & ( (trace_event_n[11] & read) | (trace_event_n[10] & write) ) ) | ( // data section ((trace_event_n[23:20] == zb_data_id) & (trace_event_n[6:5] == 2'b01))| ((trace_event_n[19:16] == zb_resp_id) & (trace_event_n[6:5] == 2'b10))| ((trace_event_n[23:20] == zb_data_id) & (trace_event_n[19:16] == zb_resp_id) & (trace_event_n[6:5] == 2'b11)) ) | // interrupt (trace_event_n[7] & edge_detect (interrupt)) | ) then trigger event n // external pin (trace_event_n[9] & edge_detect (~debug_pin)) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 72 section 4: system control and debug unit document 1250_1125-um100-r each trigger event has a counter associated with it. if the counter is greater than zero when the trigger condition is true then the counter decrements. if the counter is zero then the event is signaled to the trigger sequencers, and the counter will be reloaded with its initial value. the trace event register is shown in table 46 . there are eight such registers trace_event_0 to trace_event_7 . table 46: trace event register trace_event_0 - 00_1002_0a20 trace_event_1 - 00_1002_0a28 trace_event_2 - 00_1002_0a30 trace_event_3 - 00_1002_0a38 trace_event_4 - 00_1002_0a60 trace_event_5 - 00_1002_0a68 trace_event_6 - 00_1002_0a70 trace_event_7 - 00_1002_0a78 bits field default description 3:0 addr_match[3:0] 4?b0 each of these bits corresponds to an address trap register (see section: ?address trapping? on page 67 ). if none of these bits are set then the address on the bus is not considered as part of the trigger. if any of these bits are set then the address is considered part of the trigger, and the event only triggers if the address falls within the range specified by the corresponding trap. both simple and complex traps may be used. the event will trigger whenever there is a hit in the trap, the occurrence counter in the trap is ignored. 4 req_id_match 1?b0 when set the address portion of the event only occurs if the requester id of the transaction matches the req_id field of this register. 5 data_id_match 1?b0 when set the data portion of the event only occurs if the data id of the transaction matches the data_id field of this register. 6 resp_id_match 1?b0 when set the data portion of the event only occurs if the responder id of the transaction matches the resp_id of this register. 7 interrupt 1?b0 when set the event occurs when an interrupt that is enabled for tracing occurs. the int_trace_trigger outputs from the two interrupt mappers (see figure 10 on page 51 ) are ored together to signal the event. (no record is made of which interrupt triggered the event). the event triggers once on the assertion of the or of the two interrupt mapper outputs. before the event can trigger again the outputs of both mappers must be deasserted. 8 reserved 1?b0 reserved 9 debug_pin 1?b0 when set the event occurs if the external debug pin is pulled low. the event will trigger once on the falling edge of the debug_l pin. debug_l must return to its deasserted (high) state before the event will trigger again. 10 write 1?b0 when set the event only occurs if the transaction is a write. 11 read 1?b0 when set the event only occurs if the transaction is a read. 15:12 req_id[3:0] 4?b0 requester id used for matching. 19:16 resp_id[3:0] 4?b0 responder id used for matching. 23:20 data_id[3:0] 4?b0 data id used for matching. 31:24 count[7:0] 8?b0 if the count is not 0 then the event does not take place. instead the counter is decremented. if the counter is 0 then the event occurs and the count is restored to its initial value. writing this register sets the initial value of the counter, reading will return the current value. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 73 t rigger s equences a trigger sequence is a set of up to four conditions that must be satisfied in sequence and a trace function that will be executed when the sequence is complete. the conditions are combinations of trigger events. there are eight trigger sequencers. sequencers 0-3 have events 0-3 as their sources, sequencers 4-7 have events 4-7 as their sources. the following chart shows the combinations for sequencers 0-3 (for sequencers 4-7 add 4 to the event numbers): the codes from these events are combined to make the sequence. for example the sequence 0123 requires that event0 happens, then event1, then event2, following this when event3 happens the function associated with the sequencer will be executed. sequences of less than four events have the ignored code ( f ) in their lower bits, hence a sequence that will execute its function every time event 1 or event 2 triggers is expressed as 5fff . the functions that can be performed when a sequence is complete are: 1 start collecting samples. this enables collection of samples into the trace buffer, unless collection has been frozen. the sample that triggers the start will be recorded if the sequence is marked with one of the filter bits described below. 2 stop collecting samples. this suspends collection of samples into the trace buffer until a start function is performed. the sample that triggers the stop will be reco rded if the sequence is marked with one of the filter bits. 3 freeze the trace buffer. this stops collection of samples into the trace buffer until the buffer is reset by software or via the jtag port. the sample that triggers the freeze will be recorded if the sequence is marked with one of the filter bits. an interrupt is raised when the buffer is frozen. in addition there are three filter flags that are only used if collection is in progress: 0 - event0 1 - event1 2 - event2 3 - event3 4 - event0 | event1 5 - event1 | event2 6 - event2 | event3 7 - event0 | event1 | event2 8 - event0 | event1 | event2 | event3 9 - event0 & event1 a - event0 & event1 & event2 b - event0 & event1 & event2 & event3 c - (event0 & event1) | event2 d - (event0 & event1) | (event2 & event3) e - (event0 & event1) | event2 | event3 f - ignored bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 74 section 4: system control and debug unit document 1250_1125-um100-r a sample causes an address/control bundle to be recorded in the trace buffer. these samples are packed three per line of the trace memory, so a maximum of 768 samples can be in the buffer. note that if the final trigger of the sequence is a databus trigger then the a-phase signals captured may not be valid (the latches within the trace unit will only capture address information when an agent is driving the bus, this data is held in the latches until the next time the bus is driven). d sample causes an address/control bundle and the 32 bytes of data from the bus to be recorded in the trace buffer. a d sample always starts a new line in the trace buffer (if the previous line was only partially full from a samples the empty spaces are marked unused). so a maximum of 256 d samples can be taken. since a d sample is a superset of an a sample, if both filter bits are set a d sample is taken. when a d sample is taken the aphase signals may not be valid. clear use causes the counter that determines the buffer usage to be cleared. thus following the current sample 255 more entries will be filled before the buffer full condition is raised. this flag is normally used with the start function when the start trigger may repeat and the freeze should only come when the buffer fills after the last start. the final two flags allow the completion of a sequence to be signalled outside the trace logic (these occur regardless of the state of trace collection). debug pin causes the scd to pull the debug_l pin low for 10 zbbus clock cycles. debug cpu causes the scd to assert the debug interrupt to both cpus. the debug interrupt is cleared by a read of the trace_cfg register. the outputs from all the sequencers are combined. if multiple functions are signalled, freeze has the highest priority, then stop , then start . note that when an address based trigger is used, the data bus may not be valid. so, forcing a dsample from such a trigger could waste trace buffer entries. there are eight sequence control registers trace_sequence_0 to trace_sequence_7 , as shown in table 47 . table 47: trace sequence control registers trace_sequence_0 - 00_1002_0a40 trace_sequence_1 - 00_1002_0a48 trace_sequence_2 - 00_1002_0a50 trace_sequence_3 - 00_1002_0a58 trace_sequence_4 - 00_1002_0a80 trace_sequence_5 - 00_1002_0a88 trace_sequence_6 - 00_1002_0a90 trace_sequence_7 - 00_1002_0a98 bits field default description 3:0 event select 4 4?b0 these bits set the event selection that forms the fourth event in the sequence. the bits should all be set (the ignore code) if the sequence is shorter than four events. 7:4 event select 3 4?b0 these bits set the event selection that forms the third event in the sequence. the bits should all be set (the ignore code) if the sequence is shorter than three events. 11:8 event select 2 4?b0 these bits set the event selection that forms the second event in the sequence. the bits should all be set (the ignore code) if the sequence is shorter than two events. 15:12 event select 1 4?b0 these bits set the event selection that forms the first event in the sequence. the bits should all be set (the ignore code) if the sequence should always trigger (used with the filter bits to capture all active bus cycles). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 75 the special event selection sequence 16'hffff written in one of the trace sequence registers will cause all bus cycles to be selected. there are several possible actions depending on which of bits 18,19,23 and 24 are set: asample (bit 18): an address/control sample is taken every time the address bus is used. dsample (bit 19): an address/control and data sample is taken every time the data bus is used. alld_a (bit 23): an address/control sample is taken every time the data bus is used. asample and alld_a (bits 18 and 23): an address/control sample is taken every time either address bus or data bus is used. asample and dsample (bits 18 and 19): an address/control sample is taken every time the bus is used, with data also being captured if the data bus is used. all_a (bit 24): an address/control sample is taken on every bus cycle. using these sequences a trace of the entire active bus can be taken. to avoid the count of cycles between samples overflowing, the forcecnt bit can be set in the trace_cfg register to force an address/control sample to be taken just before overflow. the sample collected when a section of the bus is not used is unpredictable. the avalid and dvalid bits in the address/control bundle are used to indicate which bits in the bundle are valid. the all_a flag can be used in profiling to monitor the blocking and interrupt signals on every cycle. 17:16 function 2?b0 these bits set the function that should be performed when the sequence completes. 00: nop. no function is performed. 01: start. the trace collection is started. 10: stop. trace collection is stopped. 11: freeze. the trace buffer is frozen. 18 asample 1?b0 if this bit is set then an address trace is taken when the sequence completes, if dsample is set this bit is ignored, unless all the select fields are 4?hf. if the select fields are all 4?hf and asample is set then an address trace is taken every time the address bus is granted (i.e. nop cycles are included). 19 dsample 1?b0 if this bit is set then an address and a data trace is taken when the sequence completes. if the select fields are all 4?hf and dsample is set then an address and a data trace is taken every time the data bus is granted (i.e. nop cycles are included). 20 debugpin 1?b0 if this bit is set then the external debug pin is pulled low when the sequence completes. 21 debugcpu 1?b0 if this bit is set then debug interrupts will be sent to both cpus when the sequence completes. 22 clearuse 1?b0 if this bit is set then the buffer use counter is cleared, so the buffer full condition will not be raised until this buffer entry and 255 others have been used. 23 alld_a 1?b0 if the select fields are all 4'hf and this bit is set then an address/control sample is taken whenever the data bus is used. 24 all_a 1?b0 if the select fields are all 4'hf and this bit is set then an address/control sample is taken on every bus cycle. table 47: trace sequence control registers (cont.) trace_sequence_0 - 00_1002_0a40 trace_sequence_1 - 00_1002_0a48 trace_sequence_2 - 00_1002_0a50 trace_sequence_3 - 00_1002_0a58 trace_sequence_4 - 00_1002_0a80 trace_sequence_5 - 00_1002_0a88 trace_sequence_6 - 00_1002_0a90 trace_sequence_7 - 00_1002_0a98 bits field default description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 76 section 4: system control and debug unit document 1250_1125-um100-r u sing the t race b uffer the trace buffer starts off empty and tracing is disabled. the trigger events and sequencers are configured by software or over the jtag debug interface. then the system is run and the trace is recorded in the buffer. when the buffer freezes the trace can be read out, again either by software on the bcm1250 or BCM1125/h or via the jtag link. control of the trace features is done through the trace_cfg register. the jtag interface or debug software can write this register to trigger the start, stop or freeze functions, and also to reset and enable the trace buffer. the trace unit can also be set to execute the freeze function and/or the debug pin function when the buffer fills (these functions are described in section: ?trigger sequences? on page 73 ). a 64 bit register is provided for reading out the collected trace. the buffer should be frozen before samples are read out, if it is not then the results of the read are unpredictable. the startread bit in the trace_cfg register is written with a one to start the read process. then each read of the trace_read location ( 00_1002_0a08 ) will provide the next 64 bits from the trace memory. software (either on the target, or external debug agent) must post-process the trace to extract the information. (broadcom provides code to do this.) the buffer can only be read once after samples have been collected. the trace control register is shown in table 48 . table 48: trace control register trace_cfg - 00_1002_0a00 bits field default description 0 reset 1?b0 when this bit is written with a 1, the trace buffer pointers will be reset ready for collection to begin. this bit always reads as zero. 1 startread 1?b0 when this bit is written with a 1, the trace buffer read pointer and latch are prepared for reading. this bit always reads as zero. note that the buffer can only be read once after a collection, if this bit is written with a 1 for a second time the data read back will be unpredictable. 2 start 1?b0 when this bit is written with a 1, the start function is triggered, and collection will begin if the buffer is not frozen. when read this bit will be set if collection is in progress. 3 stop 1?b0 when this bit is written with a 1, the stop function is triggered, and collection will be suspended until a start if the buffer is not frozen. when read the bit will be set if collection is stopped and not frozen. 4 freeze 1?b0 when this bit is written with a 1, the trace buffer is frozen. when read this bit will be set if the buffer is frozen. the buffer must be reset to allow further collection. 5 freezefull 1?b0 if this bit is set the buffer will freeze when if becomes full. in order to prevent overflow the buffer will freeze as soon as there is any data in the final entry, if it freezes with space for two more address/control bundles (but no room for a data sample) the trcfull bit will not be set. 6 debugfull 1?b0 if this bit is set the debug_l pin will be asserted when the buffer becomes full. the debug_l pin is deasserted again when the first read of the trace buffer begins or the trace is reset. 7 trcfull 1?b0 read only. this bit is set when the trace buffer is full (if this is set 256 entries can be read from the buffer) 8 forcecnt 1?b0 if this bit is set and collection is in progress then an address/control sample is forced to be collected before the count field overflows regardless of the state of the filters. this ensures an exact count between events (at the expense of some additional entries used in the buffer. 9 reserved 2?b0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 77 all entries in the trace buffer contain an address/control bundle. the bundle includes the response phase signals that match with the address phase signals that are captured. the data phase signals are captured at the same time as the a phase signals, and have no relationship with the transaction that the a-phase and r- phase are part of. the address/control bundle is 128 bits organized as shown in table 49 . 17:10 trcaddr 8?b0 current trace buffer address. if the trcfull bit is not set this number plus 1 entries can be read from the buffer. 63:18 notimp 46?bx not implemented. table 48: trace control register (cont.) trace_cfg - 00_1002_0a00 bits field default description table 49: trace buffer address/control bundle bits field description 2:0 d_code data code (this has no relationship to the a and r phase signals). 000: nop, data invalid (gets counted as arbitrated but not used). 001: data valid. 010: data valid, tag ecc corrected (l2). 011: data valid, data ecc corrected (mem, l2). 100: bus error (io bridge). 101: fatal bus error (cache block ownership unclear). 110: uncorrectable tag ecc error (l2). 111: uncorrectable data ecc error (cpu, l2, mem). 3 d_mod d-phase indication that the data is dirty (this has no relationship to the a and r phase signals). 7:4 d_rsp[3:0] data phase responder id (this has no relationship to the a and r phase signals). 17:8 d_id[9:0] data phase transfer id (this has no relationship to the a and r phase signals). [9:6] requester id. [5:0] unique number within requester. 18 r_l2hit the l2 hit during the response phase of the a-phase transaction. 24:19 r_exc[5:0] response phase exclusive bits that match the a-phase transaction. 30:25 r_shd[5:0] response phase shared bits that match the a-phase transaction. 31 a_l2ca l2 cacheablility bit. 0: do not allocate on miss. 1: allocate on miss. 36:32 reserved always reads zeros. 37 int_trace_1 records the int_trace_trigger_1 output from the cpu 1 interrupt mapper (see figure 8) 38 int_trace_0 records the int_trace_trigger_0 output from the cpu 0 interrupt mapper (see figure 8) 39 dvalid set if the data bus had a valid cycle when the sample was captured (indicates the d_ signals are valid) 40 avalid set if the address bus had a valid cycle when the sample was captured (indicates the a_ and r_ signals are valid). 51:41 block[10:0] zbbus blocker signals. 59:52 a_byt encoded byte enables. indicates valid bytes within doublewords. byt[n=7:0] =a_be[n] | a_be[n+8] | a_be[n+16] | a_be[n+24] bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 78 section 4: system control and debug unit document 1250_1125-um100-r the data trace consists of two 128 bit entries. the first contains bits [255:128] from the databus, the second has bits [127:0]. 63:60 a_dw encoded byte enables. indicates any doublewords with valid bytes. dw[n=3:0] = a_be[8*n + 0] | a_be[8*n + 1] | a_be[8*n + 2] | a_be[8*n + 3] | a_be[8*n + 4] | a_be[8*n + 5] | a_be[8*n + 6] | a_be[8*n + 7] if only one doubleword is set then the byt field indicates the valid bytes, if more than one doubleword is set then knowledge of the transaction will be needed. other than uncached accelerated writes, all cpu transactions will be within a single doubleword or of the full cacheline. 65:64 a_l1ca l1 cacheablility bits. 00: cacheable non-coherent. 01: cacheable coherent. 10: uncacheable. 11: uncacheable (accelerated, may have merged writes). 68:66 a_cmd address phase command bits 000: read_shd. 001: read_exc. 010: write. 011: write and invalidate. 100: invalidate. 101-110: reserved 111: no command valid. (nop) 103:69 a_ad[39:5] line address of the transaction on the bus. 113:104 a_id[9:0] this is the value of the address id bits on the bus. a_id[9:6] - requester id. a_id[5:0] - unique number within granted requester. 125:114 count this is the number of bus cycles between the last traced entry and this entry. this is a 12 bit saturating counter. if two samples are captured on consecutive cycles the count will be zero. the count is set to zero when the trace buffer is reset. 126 dtrig this bit is set when a sequence completing with dsample caused this control entry to be traced. the next 256 bits contains the data bits [255:0]. 127 atrig this bit is set when a sequence completing with asample caused this control entry to be traced. table 49: trace buffer address/control bundle (cont.) bits field description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 79 r eading the t race b uffer each entry in the trace buffer is 384 bits, and falls in to one of two possible formats. format 1 is used when the entry contains one to three address/control samples, the first bundle (t0) will always come from an address trigger (the atrig bit will be 1) and will indicate format 1 by not having an associated data sample (the dtrig bit will be 0). note that if the sample was forced by an all-bus-cycle trigger, a data trigger or to avoid the inter- sample interval count overflowing, the avalid bit may be clear indicating the a-phase information is invalid. the dvalid bit indicates if there was databus activity when the sample was taken and the d-phase information is valid. format 2 covers the address and data sample, in this case there may or may not have been an address trigger (atrig could be either 0 or 1) but there will always have been a data trigger (dtrig will be 1). again the avalid and dvalid bits in the control bundle indicate what activity was on the bus and thus which fields of the sample are valid. software or the jtag probe must perform six reads to collect the entire sample before decoding it. table 50 describes the entry formats and the order in which they are read. when all the entries have been read from the buffer the atrig and dtrig bits are forced to zeros in any subsequent reads. this condition can be used to terminate reading the buffer, or the trcfull and trcaddr fields of the trace_cfg register can be used to compute the number of entries that should be read. the startread bit in the trace_cfg register must be written with a 1 before the trace can be read out. the buffer can only be read out once, any additional attempts will return unpredictable data. table 50: trace entry format and read order bits read order format 1 (address/control) format 2 (address/data) 383:320 1 address/control bundle t2 [127:0] this is the third sample recorded in this entry. it may not be valid. data [255:0]. 319:256 2 255:192 3 address/control bundle t1 [127:0] this is the second sample recorded in this entry. it may not be valid. 191:128 4 127:64 5 address/control bundle t0 [127:0] this is the first sample recorded in this entry. it will always be valid for a format 1 sample. the dtrig bit will be 0. address/control bundle t0 [127:0] this is the address sample captured with the data. it may not be valid. the dtrig bit will be 1. 63:0 6 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 80 section 4: system control and debug unit document 1250_1125-um100-r an algorithm for decoding the bundle is: the entries are returned with the newest one first and the earliest available read out last. the postprocessing software must take care to reverse the order to show causality. if (b[127]==1) { if (b[126]==1) { /* have valid address and valid data sample */ format = 2 } else { format = 1 if (b[255] == 0) { /* have 1 valid address sample */ } else if (b[383] == 0) { /* have 2 valid address samples */ } else user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 81 m agic d ecoder r ing f or u sing t he t race b uffer this section includes some notes for using the trace buffer when debugging. nothing in this section is part of the official specification of the device and things (in particular the tid information) could change from revision to revision. the trace control entries include the transaction id generated by the source of the transaction. in many cases additional information about the transaction can be deduced from the tid. for chips with system revision indicating periph_rev3 table 51 gives some details. table 51: decode of some tids for system revision periph_rev3 tid[9:6] agent id see table 1 tid[5:0] set by the agent description cpu 000x 11nnnn instruction fetch. 000x 000nnn read for read queue entry nnn. 000x 10nnnn write or evict. bridge 0 0010 00pnnn read from port p (1=pci, 0=hypertransport). 0010 01pnnn write from port p (1=pci, 0=hypertransport). 0010 10pnnn read-modify-write (i.e. partial line write) from port p (1=pci, 0=hypertransport). bridge 1 0011 00pnnn read from dma engine p (1=serial, 0=mac). 0011 01pnnn write from dma engine p (1=serial, 0=mac). 0011 10pnnn read-modify-write (i.e. partial line write) from dma engine p (1=serial, 0=mac). scd 0100 cc00aa read for buffer aa of channel cc. (cc bits always 00 prior to periph_rev3) 0100 cc01aa write of buffer aa of channel cc. (cc bits always 00 prior to periph_rev3) 0100 cc11aa read for read-modify-write with buffer aa of channel cc. (cc bits always 00 prior to periph_rev3) 0100 cc1000 descriptor fetch for channel cc. (cc bits always 00 prior to periph_rev3) 0100 001001 jtag probe transaction. (010000 prior to periph_rev3) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 82 section 4: system control and debug unit document 1250_1125-um100-r table 52: encoded byte enables for cpu transactions cpu operation doubleword a_dw byte a_byt comments cacheable fill or evict or instruction fetch 1111 11111111 cacheable operations always move a full block, so the byte enables can be ignored. uncacheable instruction fetch 1100 0011 11111111 uncacheable instruction fetches always fetch four instructions (either the first or second half of a cache block). uncacheable lb/sb one bit set one bit set the byte can be identified from the encoded enables. uncacheable lh/sh one bit set 11000000 00110000 00001100 00000011 the half word can be identified from the encoded enables. uncacheable lw/sw one bit set 11110000 00001111 the word can be identified from the encoded enables. uncacheable ld/sd one bit set 11111111 the double word can be identified from the a_dw code. uncacheable lwl/lwr/swl/swr one bit set 1-4 bits set the bytes can be identified from the encoded enables (but some combinations will match word/halfword/byte accesses). uncacheable ldl/ldr/sdl/sdr one bit set 1-8 bits set the bytes can be identified from the encoded enables (but some combinations will match double/word/halfword/byte accesses). uncached accelerated writes 1-4 bits set 1-8 bits set if only doubleword stores are involved they can be identified. if word stores are used then information may be lost (reconstruction may be possible from the source code). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 83 c onnections to the t race l ogic the trace logic connects to many other parts of the scd. figure 11 shows these connections. figure 11: connections to trace logic system events zbbus address traps performance counters interrupt mapper debug pin trace events trace sequences jtag trace buffer jtag cpu interrupts c a p t u r e full cpu debug freeze match trace interrupt interrupt trace overflow match m a t c h c o u n t e d bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 84 section 4: system control and debug unit document 1250_1125-um100-r t race e xample 1: a ll cpu0 a ctivity the code running on cpu0 is being monitored, for a particular section of code all address bus activity will be recorded to check the l2 cache behavior. the code is patched to do a dummy access to an address at the start and end points of the code to trace, and the trace buffer is set up: when cpu0 accesses the dummy start address trace1 and seq0 will cause trace collection to be started. then trace0 and seq1 will cause every address requested by cpu0 to be written to the buffer, until the dummy access that causes trace2 and seq2 to stop collection (the a-sample bit could be set on this sequence to record the dummy access if a separator was required). when the trace buffer is full, the trace_cfg setting causes it to freeze, and raise an interrupt. cpu0 would service this interrupt and (with as little cache disturbance as possible) read out the trace into a bigger in- memory buffer. at the end of the isr the trace buffer is reset and started (it must have been collecting for it to fill) and collection continues. at the end of the test the buffer would be frozen by software and the final samples copied to the memory buffer. the memory buffer would then be post-processed for analysis. addrmatch0 = start trigger addrmatch1 = stop trigger trace0 = reqid=cpu0 & (read|write) trace1 = reqid=cpu0 & addrmatch0 & (read|write) trace2 = reqid=cpu0 & addrmatch1 & (read|write) trace_cfg = freezefull seq0 = trace1, ignore, ignore, ignore -> start seq1 = trace0, ignore, ignore, ignore -> a-sample seq2 = trace2, ignore, ignore, ignore -> stop user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 85 t race e xample 2: n etwork p acket h eaders this example uses the trace buffer as a non-obtrusive record of the most recent network packet headers that were received from one of the macs. it could be used, for example, when there is a bug that is thought to be caused by the processing of some rare sequence of network packets. the trick is to notice that the dma controller will always write the receive dma status back into the dma descriptor at the end of packet reception. this is used to prime collection of the first two transfers of the next packet. the first address trap is set up to detect the range of addresses that cover the receive dma descriptor ring. trace0 detects a write to this space from the i/o bridge that connects the macs. this write is done at the end of a packet reception to put the status flags into the descriptor (the requester id is needed here because the cpu will also be writing the ring to update the descriptors). seq0 uses this to start the trace collection. when a packet arrives the dma will write it to memory in 32 byte cache line chunks. the address associated with the write request triggers trace1 , and seq1 filters it to be recorded (this may not be needed in this example, and will be fairly costly because it will unalign the trace buffer pointer from the entry boundary). the trace2 is used to detect a write data transfer from the mac to the buffer memory. it does this by detecting a transfer on the data bus where the data source (in the resp_id field) and the initiator of the transaction (in the data_id field) are the same. this is enough to detect that some write data is in flight from the i/o bridge. the seq2 sequence will first need trace1 to detect the write request to the buffer addresses before looking at trace2 to detect the data transfer part of the transaction. when the sequence is triggered the data sample is taken and written to the trace buffer. since the network packet header is in the first 64 bytes of the packet only the first two dma transfers should be recorded. seq2 will trigger on both, causing data to be written to the trace buffer. seq3 has to see both transfers before it triggers and stops collection. this process repeats, using the trace memory as a ci rcular buffer, until the freeze command is given (by software writing the trace_cfg register). at this point the trace buffer can be read out, showing the last 64 packet headers. (two lines in the buffer are used up for each dma transfer recorded -- the first has the seq1 address sample and two empty slots, and the second the seq2 address/data sample. since the first two transfers of each packet are recorded there are 4 trace buffer lines per packet). addr0 = range of receive dma descriptors for the mac addr1 = range of receive buffers trace0 = reqid=iobr1 & addrmatch0 & write (a phase of descr write) trace1 = reqid=iobr1 & addrmatch1 & write (a phase of write) trace2 = rspid=iobr1 & dataid=iobr1 (write data from iobridge) seq0 = trace0, ignore, ignore, ignore -> start seq1 = trace1, ignore, ignore, ignore -> a-sample seq2 = trace1, trace2, ignore, ignore -> d-sample seq3 = trace1, trace2, trace1, trace2 -> stop bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 86 section 4: system control and debug unit document 1250_1125-um100-r t race e xample 3: pci d river d ebugging device drivers for pci devices quite often rely heavily on macros and library input/output routines. particularly when porting code from a little endian (e.g. x86) driver to the bcm1250 or BCM1125/h running big endian, it can be hard for the programmer to track down exactly what is being transferred back and forth to the device on the pci bus. this example uses the trace buffer to record every transfer between the cpu and the pci bus, and any dma activity initiated by the pci device. the driver code has writes to the trace_cfg register added to start and stop samples, and to freeze and read out the results. any access from the cpu to the pci range is detected by trace0. if the transaction is a write then trace2 will detect the data transfer; the resp_id indicates that the data source is the cpu and the data_id indicates that the transaction was initiated by the cpu. (this detects any write data from the cpu, it is used in sequence with trace0 to detect this particular write.) if the transaction is a read then trace3 detects the data returning from the i/o bridge in response to the cpu request (the i/o space read is uncacheable and the cpu only has one outstanding, so in sequence with trace0 this always catches the correct data). master mode accesses from the pci are detected by trace1 for addresses and trace4 for the data these just use the transaction id to identify the i/o bridge as the initiator of the operation. note that since trace4 is used the detection sequence had to move to seq4 on the sec ond sequencer block. this will detect dmas from devices on the hypertransport fabric too, so this is not a perfect trace. however, since it is being used to debug during the device driver bring-up, it should be relative ly easy to prevent other dma devices from being active. addr0 = pci range trace0 = reqid=cpu0 & addrmatch0 & (read|write) trace1 = reqid=iobr0 & (read|write) trace2 = rspid=cpu0 & dataid=cpu0 trace3 = rspid=iobr0 & dataid=cpu0 trace4 = dataid=iobr0 seq0 = trace0, ignore, ignore, ignore -> a-sample seq1 = trace0, trace2 | trace3, ignore, ignore -> d-sample seq2 = trace1, ignore, ignore, ignore -> a-sample seq4 = trace4, ignore, ignore, ignore -> d-sample user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 4: system control and debug unit page 87 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 88 section 4: system control and debug unit document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 5: l2 cache page 89 section 5: l2 cache i ntroduction the on-chip second level cache is shared by the processors and any i/o dma masters. on the bcm1250 the l2 cache is 512 kbytes, on the BCM1125/h it is 256 kbytes. this section describes the normal operation of the l2 cache, a mode where banks of it can be used as an on-chip sram and the management interface to it. after reset the management interface must be used to initialize the l2 cache before it can be used, if a cacheable reference is made before the l2 is initialized multiple cache lines may be selected causing an internal bus clash. n ormal o peration the l2 cache is 256 or 512 kbytes, organized into 32 byte cache lines four way set associative. all accesses to the l2 are in full cache blocks. it is a non-inclusive/non-exclusive cache, thus there are no restrictions on which cache blocks can be in the l2. a random replacement policy is used when a victim line must be found. the l2 runs internally at the cpu core speed and is fully pipelined. this allows one access per zbbus cycle, including all the required housekeeping needed to evict dirty lines. the l2 cache tags and the data blocks are ecc protected. single bit errors in either are corrected while an access is in progress (the l2 will internally take time to perform the full recovery, but the system continues running). the ecc cleanup is started by a cache hit on a line with a single bit error. cleanup will be pre-empted by a write to another way at the same index, so occasionally a single bit error will be flagged twice. tags with uncorrectable errors result in unpredictable data being returned to the requestor with an uncorrectable tag error signalled. data with uncorrectable errors will be returned to the requestor with an uncorrectable data error signalled. in either error case software recovery is required. the bus watcher in the scd will log the data associated with the error and raise an interrupt. the l2 will record the tag associated with the error in the l2_ecc_tag register (this can be read to give the tag from the most recent ecc error). the management interface to the l2 can be used to invalidate the line and clear the ecc bits. any data that is received by the l2 cache marked with an error is written into the cache with an uncorrectable ecc error, so subsequent reads will also get an error. the l2 cache is physically one of the zbbus agents, but architecturally it sits between the system bus and the main memory, and there are dedicated signals between the l2 and memory controller that coordinate them. every bus access is accompanied with the l1 cache and coherence attributes for the access. in the cpu these are set in the tlb and indicate cacheable-coherent, cacheable-non-coherent, uncacheable, and uncacheable- accelerated (which indicates writes may have been merged). for dma accesses the l1 attributes are provided from the dma control registers and should match the attributes the cpus use for that area of memory. the l2 is coherent with memory for all l1 cacheable accesses (non-cacheable accesses to main memory will bypass the l2 cache, they should never be done to areas of memory that have previously been cacheable). the l2 cache is checked by all l1 cacheable memory accesses put on zbbus. as described in section: ?coherence? on page 12 , it acts in conjunction with the memory controller to provide any blocks that are not owned exclusively by another bus agent. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 90 section 5: l2 cache document 1250_1125-um100-r every bus request is accompanied by an l2 cacheability flag, if this is set and the block is not in the l2 cache then it will be allocated. on a write miss the l2 will allocate space for the block and accept the data when it is transmitted. on a read miss the memory controller will supply the data to the requesting agent, the l2 will allocate space for the block at the time the request is made and will take a copy of the data as it passes on the bus. the l2 cacheability flag only affects the behavior on an l2 miss. regardless of the l2 cacheability flag, if a request that is l1 cacheable hits in the l2 then it will supply the data for a read and receive the data on a write. the l2 cache behaves the same whatever the source of the request, so dma masters will read data from the l2 if it is there. more interestingly, dma writes can be done with the l2 cacheability bit (see a_l2ca in section: ?address phase? on page 22 ) set to cause the data to be written to the l2 cache (and on to memory only if it gets evicted). this can be used to reduce the access latency for any data the cpu will need to manipulate. however, this operation can potentially pollute the l2 cache so it must be used with care. the internal dma controllers have a control bit to enable this behavior, its use by external dma masters is described in the host bridge section for the buses. to allow programs further control of the l2 cache, the cpu provides a mechanism to prevent the l2 cacheability flag from being set on accesses that are cacheable in the l1 cache. this is of particular use for reducing l2 pollution with data that is highly likely to be referenced only by one of the cpus and used for a short time. there are two ways this can be done. pages can be marked in the tlb with one of the cacheable coherent no l2 attributes (codes 0 and 1), which will cause all blocks in the page to be accessed with the l2- allocate flag clear. alternatively, the pages can be marked with the usual cacheable coherent attributes (codes 4 and 5) and the prefetch instruction with a streaming hint can be used to access individual lines around the l2 cache. in the second case since the block is marked for streaming when it is put in to the l1 it is flagged as the first of the 4 lines at that index to be evicted (it will be evicted first regardless of the lru information). when the l2 cache is accessed address bits [16:5] ([15:5] on a part with or configured for a 256kb cache and [14:5] for a part with or configured for a 128kb cache) are used to form an index into the cache array, and the four ways are examined at that index. when designing for best performance the potential for bad aliasing must be taken into consideration. for example in an embedded system using 64k pages and a simple memory allocator, it is possible that memory is always allocated in 64k chunks starting at a page boundary. thus (for a 512kb cache) data in the first cache block of allocated objects will be found at one of 8 locations in the l2 cache (the index will either be zero or have just bit [16] set, and there are 4 ways at each possible index). a programmer unaware of the allocation policy could see a large amount of unexpected cache thrashing, and thus get significantly lower performance than expected. a similar (though less dramatic) effect can be seen if network packet buffers are allocated as 1kb long aligned at a 1kb boundary and the dma engine is set to cache 64 byte headers in the l2. the packet headers will all have address bits [9:6] as zero, so will be limited to use 1/16th of the cache. if 64 bytes of padding is put between the buffers (or the buffer size is increased to 1088) then all of the cache will be used. statistics for the l2 cache are gathered by the debug/performance monitor unit. these are discussed in the section: ?system performance counters? on page 61 . user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 5: l2 cache page 91 u sing the l2 c ache as m emory some applications require more control over the on-chip memory than is provided by a cache, and would work best with a local ram. a fast ram can be provided by removing ways from the l2 cache. each way that is removed from the cache provides a 128 kbyte memory that can be accessed at the same speed as the l2 (or 64kb memory on a 256kb cache). ways are removed from cache use (they are removed from the random replacement algorithm) by clearing the bit corresponding to the way number in the l2_wayen[3:0] register. this is a control register hidden in the l2 cache that can be updated by doing a write to the l2_way_enable space as shown in figure 12 . whenever any write is made to this address range the data is ignored, and bits [11:8] of the address get written to bits [3:0] of the register that enables the way. this register resets to have all bits set, so all ways of the cache are enabled. to remove way 2 from the cache and enable all the other ways the access address would be to the l2_way_enable space with address bit 10 clear and the others set, giving an address of 00_1004_1b00 . software should not clear all four bits in the l2_wayen register, the resulting behavior of the cache is unpredictable if there is any l2 cacheable activity in the system (the system will not hang, but data corruption will occur in one way of the cache). on parts with system revision indicating periph_rev3 and later the register can be read back from the l2_misc_value register. figure 12: level 2 cache way disable access address the memory removed from the cache must always be accessed as cacheable space. cacheable transfers are always done as full blocks and the l2 cache always operates on full cache lines. writes smaller than a cache line (which will be the case for most uncacheable stores) will result in the whole line being written with unpredictable data. the ecc logic remains active for the memory. on writes the correct ecc is generated and written. on reads the ecc is checked, correctable errors are fixed and uncorrectable errors are flagged as data errors. removing ways from the l2 cache reduces both its size and associativity. this is likely to impact the performance of the processors. a system design trade-off must be made between the control given by having the local fast memory, and the degradation of cache performance. in general purpose systems using all the memory as cache is most likely to be the best solution, in well-characterized embedded applications removal of one way of the l2 cache can improve the predictability of critical loops. there are two main methods for using ways removed from the l2 cache. the simplest is just to use the memory as a block of on-chip ram with a fast access time (that initially contains random data). the second method is to load data from main memory into the l2 cache and then lock it in place by preventing it being replaced. 01 39 32 31 28 27 20 15 12 11 8 19 7 0 0 24 16 0 041 written to l2_wayen[3:0] 43 0 35 36 0 23 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 92 section 5: l2 cache document 1250_1125-um100-r s tandard ram ways removed from the l2 cache can be used as a standard ram block by accessing the memory using the management access address range with the way bits set appropriately and the special control bits set to zero (the management mode is described in section: ?cache management access? on page 94 ). this provides a bank of memory that the system will need to initialize and that has no corresponding main memory locations. if consecutive ways are removed from the l2 cache the banks provided will be contiguous, forming a larger memory. table 53 shows the address range that should be used for each ram bank. note that special management accesses can be invoked by using addresses other than those listed, potentially corrupting the data. figure 13 on page 95 gives details on how these addresses were derived. the special ecc diagnostic mode bits are clear, the valid and dirty bits are set and the way bits match the desired way. bits [26:23] are ignored by the access (although they get written to the cache tag), so there are 15 aliases to the addresses in table 53 that will work equally well. m emory l ocked in the l2 c ache the second method for using the l2 cache as a controlled memory is to lock data into it. the l2 is initialized with the data from main memory before the way is removed from the replacement algorithm, then any accesses to those main memory addresses will always access the l2 cache. this scheme is more complicated to set up and care must be taken that the addresses to be locked do not collide in the cache (since only one way is being locked only one address can be used per cache index), however it may be useful for code or data that cannot be easily relocated. one method to initialize the cache is to ensure there are no copies of the code in l1 or l2 caches (since the initialization would most likely run as the system boots, it may be possible to arrange this by design). three ways of the l2 cache are then disabled and cacheable reads are used to fetch the code or data into the fourth way. once the data is in place the three ways are enabled and the fourth way disabled, locking the data in the cache. as with any l2 cache manipulation, care must be taken to ensure that there is no other activity in the system during this process. table 53: addresses for memory banks way base end (for 512kb cache) end (for 256kb cache) 0 00_d018_0000 00_d019_ffff 00_d018_ffff 1 00_d01a_0000 00_d01b_ffff 00_d01a_ffff 2 00_d01c_0000 00_d01d_ffff 00_d01c_ffff 3 00_d01e_0000 00_d01f_ffff 00_d01e_ffff user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 5: l2 cache page 93 c omments on u sing the l2 as m emory this section discusses some of the system design trade-offs associated with using the l2 cache as memory, and some of the associated questions. in normal operation the l2 cache is 512kb or 256kb and 4 way associative. there is no on chip memory. in general this is the best combination, since the goal of a cache is to automatically keep recently used information in fast on-chip memory and spill older data out to the main memory. however this is statistical, there are no guarantees of behavior because sometimes a full memory cycle will be needed. turning a way of the cache into a memory bank will give some memory with guaranteed (fast) access time (subject only to bus contention), but the performance of the cache is degraded both because it is smaller and because the associativity has reduced. there is no easy way to tell what the performance impact will be for an embedded system without modeling the details (there are many studies of general computing systems but they are less useful because most uses of the part will have a much higher amount of i/o buffer and descriptor manipulation than the studies typically include). the l2 cache is non-inclusive and non-exclusive (i.e. what is in the l2 and what is in the l1 need not be related) which mitigates the effects some amount. but with a smaller l2 there is very likely to be reduced performance. on the other hand on a bcm1250 a 256kb 2 way associative cache (i.e. with half of the cache set aside as on chip memory) may be sufficient for the control processor if the task is split such that the other cpu is running a real-time-loop. the real time processor can reduce its impact on the l2 cache by keeping its main code loop in its l1 instruction cache and most of its data either in its l1 data cache or fetched around the l2 from a large table in memory (using prefetch for streaming or by mapping the page with the no-l2 allocate cache attribute). when the l2 cache is used as memory there is a restriction that writes must always be of full 32 byte cache lines. in practice this is not a problem. the space must be mapped cacheable in the cpus (which is reasonable for data that needs a fast access time), this is not a burden for i/o devices doing dma since the coherence protocol will ensure the most up to date copy of the data is returned for a dma read and the latency is about the same regardless of whether the data comes from the l1 or l2 cache. in cacheable space the cpu will only do full 32 byte block reads (to fill the l1 cache line) and full 32 byte block writes (when a line is evicted from the l1 cache), so the full line write requirement is met. th e i/o bridges (the point at which any dma traffic hits the coherent domain) recognize the l2-as-memory addresses as coherent memory space so on a read will use the coherence protocol to get the latest data, and if a partial block write (i.e. <32 bytes or not cache aligned) is made the i/o bridge will do a read (exclusive)-modify-write of the full line to coherently merge in the new data. therefore the full line write requirement is met in this case too. the data mover has the same restriction as the cpu: the space must be marked cacheable to ensure full line writes. another option that should be considered rather than using the l2 cache as memory is to make use of the l2 as a cache in which i/o devices can cache data. the zbbus l2ca flag causes an l2 cache allocate on a miss. this flag accompanies every bus command (see section: ?address phase? on page 22 ). the on-chip dma engines can be configured to assert the flag to cache descriptors and/or packet headers. hypertransport devices can assert the flag by setting the isochronous bit in a hypertransport command or (with revision 3 of the interface system revision periph_rev3) hitting in an address range defined by the isocbar and isocmask. pci devices can assert it through the mapping in the bar0 translation registers. using this rather than partitioning the cache will allow the cache to behave as a cache and store recently accessed data. this will work well in situations where the cpus are expected to be manipulating packet headers and descriptors shortly before (on transmit) or after (on receive) the i/o device. the drawback of this method is that occasionally the data cached by the i/o device will cause some cpu cached data to be evicted and force the cpu to re-fetch it from memory (this is always true of the other cpu as well), and in overload, newly arrived packets will displace older ones in the cache, so as the processors try to catchup, they will have to re-fetch from memory (this can be easily prevented by detecting overload and flipping the bit in the dma controllers to disable the l2ca flag). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 94 section 5: l2 cache document 1250_1125-um100-r r educed c ache s ize the bcm1250 can be used to develop code for lower end members of the sibyte processor family. to allow performance tuning, the l2 cache size can be reduced to match the other parts, otherwise any performance numbers may be skewed by the large l2. a 4 bit register l2_cache_disable is used for this. it is similar to the l2_way_enable register in that it is hidden and written from address bits. the register is accessed by writing dummy data to address 00_10042r00, bits [11:8] (denoted r ) are the control. on parts with system revision indicating periph_rev3 and later the register can be read back from the l2_misc_value register. to restore the full 512k l2 cache r should be 4'h0. for a 256k 4 way associative l2 cache r should be 4'h1 or 4'h2. for a 128k 4 way associative l2 cache r should be 4'h5 or 4'h6 or 4'h9 or 4'ha. other values of r will give undefined results. c ache m anagement a ccess in addition to regular accesses to the l2 cache there is a management mode. this is used to invalidate the cache when the system is reset, and is used during recovery from uncorrectable ecc errors. it can also be used to force dirty lines to be flushed from the l2 cache, however this should never be necessary in normal operation. there are two memory mapped registers associated with the management mode. performing cache operations using the management mode requires software to maintain ordering and control of traffic to the l2 cache. accesses to the l2 cache by the other cpu or dma engines could cause the cache operation to fail. in normal systems management access es are only required as part of system startup or to recover from uncorrectable ecc errors, so it should be possible to have this exclusive access. a portion of the address space ( 00_d000_0000 - 00_d7ff_ffff ) is allocated to l2 cache management operations. accesses in this range (called ?management reads? or ?management writes? in this section) will be ignored by the memory controller and will always hit in the cache even when the access made is uncacheable. the usual lower address bits select the cache index, two address bits select the way of the cache. figure 13 on page 95 and table 54 on page 95 show how a cache management address is created user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 5: l2 cache page 95 . figure 13: cache management address 0 0 d valid dirty way index 39 32 31 28 27 21 18 17 16 15 5 20 4 0 0 26 19 tag tag ecc 6 bits 32 bytes data ecc 10 bits tag tag ecc 6 bits 32 bytes data ecc 10 bits tag tag ecc 6 bits 32 bytes data ecc 10 bits tag tag ecc 6 bits 32 bytes data ecc 10 bits data data data data way = 00 way = 01 way = 10 way = 11 written to tag during write index = 0 . . . . . . . . . . . . . . . . . . . . index = 4095 ecc_ diag 22 23 index = 2047 table 54: management address bits use 4:0 offset (always 0, or treated as such by l2). 16:5 index. the cache is divided in to sets, each containing four 32 byte lines. these bits select which set is indexed. the bcm1250 has all 4096 sets, the BCM1125/h has only 2048 so bit 16 is not part of the index. bits 16:15 are also written to the tag (they are used as tag bits in 256 kb and 128 kb cache configurations). 18:17 way. these bits select which of the four lines in a set are accessed. during management writes these address bits are written to the tag. 19 dirty. the dirty bit indicates that the line held in the l2 cache contains more recent data than the block in main memory. if this bit is set the block must be written back to memory before the line can be used for another block. during management writes this address bit is written to the dirty bit and the tag. 20 valid. the valid bit indicates that the line contains valid data. during management writes this address bit is written to the valid bit and tag. 22:21 ecc_diag[1:0]. if this field is nonzero during a management mode access an ecc diagnostic access is performed. during management writes these address bits are written to the tag. 26:23 during management writes these address bits are written to the tag. 39:27 b0000000011010 ( 00_d000_0000 - 00_d7ff_ffff ) this address range selects management access. during management writes these address bits are written to the tag. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 96 section 5: l2 cache document 1250_1125-um100-r management accesses may be done with cacheable or non-cacheable operations. however, the l2 cache will always operate on a full 32 byte cache line. on reads there is not a problem since the destination will filter the data (data is always carried on its natural byte lane on the zbbus), but writes that are smaller than a cache block will cause random values to be written to the other bytes in the line. uncacheable writes will normally be smaller than a full cache block (the exception being uncached-accelerated writes that have merged to a full block in the cpu write buffer), so they cannot be used to set particular values in the cache. however, uncached writes may be used for initializing the cache (where the data is unimportant, since the goal is to clear the valid bit for all the lines in the cache) or clearing data ecc errors by overwriting the bad data. this works because the other bytes on the bus during an uncached write will always be driven with valid (although unpredictable) data. the management accesses will still signal hit or miss to the performance counters based on the comparison between the management access address and the cache tags. following any management access to the cache that is to an enabled way, the replacement algorithm state is set such that the way of the cache that was accessed is used for the victim (if one is needed) on the next cache access (note this is the next access not the next miss). therefore a line can be flushed from the cache by doing a management read of the line to be flushed followed by a regular cacheable read of a block that uses the same index and is not currently in the l2. the management access selects the way as the victim for the subsequent fill. to avoid the line being flushed ending up in the l1 cache, the management access is likely to be uncacheable, however the regular access must be cacheable. the ordering must be maintained by software (an alu operation can be performed on the data returned by the uncached management access to ensure it has completed before the cacheable load is issued). if multiple lines are to be flushed care should be taken that the dummy cacheable fetch has completed before the next uncacheable management access (i.e. an alu operation should be performed on the dummy data or a sync used). management mode accesses flow through the same paths as normal accesses. if a write is done to a line followed by a read of the same address, the data used to satisfy the read may be bypassed from the cache input queue. this increases the performance in normal operation, but is a problem when the cache ram is being tested. there must be more than six zbbus cycles between the write data (i.e. the zbbus d-phase for the write transaction) and the read request (i.e. the zb bus a-phase for the read transaction) arriving at the cache to ensure the read is from the ram array. th is can be arranged by doing two reads from the same location. alternatively, a sequence of writes to other addresses can be done before the read. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 5: l2 cache page 97 s tandard m anagement m ode a ccesses ( both ecc_ diag address bits zero ) standard management mode accesses are any made to the management address range with the ecc_diag address bits clear. management reads will return the line from the addr essed index and way. the normal ecc checking and correction is performed. data with correctable ecc erro rs will be returned with the errors corrected, flagged as ecc corrected. data with uncorrectable errors will be flagged with the uncorrectable data ecc error code. similarly, if the tag has a correctable ecc error it will be corrected and the data returned with the tag ecc corrected flag, and if the tag has an uncorrectable ecc e rror data is returned with the uncorrectable tag error code. as the management read is done the tag associated with the entry is transferred to the l2_read_tag register. this register will contain the tag after ecc correction and the raw tag ecc bits. the register can be read by the cpu with an uncacheable read. if cacheable reads are used for the management read that gets the data care is required since the cpu implements run-under-miss and there is no ordering guaranteed between cacheable and uncacheable reads. the ordering can be forced by the cpu performing a sync or an alu operation on the data read from the cache management access (e.g. add zero) before reading the tag register. there is no ordering problem if the management access is done using an uncacheable read because the cpu will maintain the order between the management access and the l2_read_tag register, but uncached access is less efficient if all the data in the line needs to be examined. management writes will write the data to the addressed index and way. the data is written with correct ecc bits. the previous data in the addressed cache line will be lost, evicts are never done. if the previous data had an ecc error this will not be reported. a new cache tag (with correct ecc) is written, tagging the line with the address used in the write (the bits put in the tag are shown in figure 13 on page 95 ). the valid and dirty bits of the tag are copied from bits 20 and 19 of the address. the l2 cache can be invalidated by doing standard management writes to each index and way of the cache using an address that causes the tag to be written with the valid bit clear. in addition to invalidating the cache this will cause correct ecc to be written to all the cache blocks and tags, so there will not be spurious ecc errors on the first use of a cache line. this must be done during system startup before the cache can be used. ecc error recovery code should not directly read the erroneous data from the cache. if the data contains an uncorrectable error it will still be signalled as such, so the cpu would see it as a cache error. however the bus watcher in the scd logs the data whenever an uncorrectable error is reported, and the l2 controller logs the address and tag (with the error) in the l2_ecc_tag register. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 98 section 5: l2 cache document 1250_1125-um100-r ecc d iagnostic m anagement a ccesses (ecc_ diag bits nonzero ) management accesses with the ecc_diag field nonzero modify the behavior of the cache to allow access to the raw memory bits for testing. management reads with the ecc_diag [0] bit set will return the raw data from the addressed index and way. the data ecc checking and correction is disabled, the raw data from the cache memory array will be returned and will always be marked valid. as the management read is done the tag associated with the entry is transferred to the l2_read_tag register. again the ecc correction is modified. the register will contain the raw tag data and the raw tag ecc bits. the register can be read by the cpu as in the standard management access, with the same care required about read ordering. the ecc_diag address field modifies the behavior of management writes to allow data and tag ecc errors (of any number of bits) to be written into the cache, to test both the hardware and software ecc detection and recovery mechanisms. management writes with the ecc_diag address field nonzero are used to check the ecc bits. the combinations allow direct writes from the data into the cache tag, and can write using ecc information from a previous write. table 55 summarizes the operations. data ecc errors can be stimulated with two writes. the first write (which is a normal write or standard management write) sets the index and way for the test along with the data ecc bits to be used for the test. the second write (an ecc diagnostic write of type 2?b01) replaces only the actual data. if the data of the second write differs by a single bit from the data in the first write a subsequent standard read will get the data from the first write flagged with a corrected ecc error. if the second write had two bits difference the subsequent read will get an uncorrectable ecc error. tag ecc errors can also be stimulated with two writes. the first write writes the tag bits with correct ecc to be used for the test (using ecc diagnostic write of type 2?b10). the second write changes the tag bits but uses the ecc bits from the first write (using an ecc diagnostic write of type 2?b11). if the tag generated by the first write differs by a single bit from the tag in the second, a subsequent standard management read will be flagged with a corrected tag ecc error and the l2_read_tag register will hold the reconstructed tag for the second write. if the tag generated by the first write had two bits difference the subsequent read will get an uncorrectable tag ecc error. table 55: ecc diagnostic operations ecc_diag[1:0] read write 2?b00 normal normal 2?b01 raw access ecc disabled write data to the cache, write the tag from the data bits. generate tag ecc bits. the tag address bits are written from zbbus bits [23:0]. the tag valid bit is written from zbbus bit [24]. the tag dirty bit is written from zbbus bit [25]. note that these are from the double-word at offset h18. 2?b10 reserved write current data with the ecc bits from the previous cache write. 2?b11 reserved write data to the cache, write the tag from the data bits (as in code 2?b01). use tag ecc bits from the previous write. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 5: l2 cache page 99 c ache c onfiguration r egister there is a 4 bit register l2_misc_config that can be used to modify the l2 behavior. it is similar to the l2_way_enable register in that it is hidden and written from address bits. in most systems this register should not be modified. the register is accessed by writing dummy data to address 00_10043r00. bits 8 and 9 are reserved and should be written as zero. if bit 10 is set the l2 cache will use the low priority memory controller blocker rather than the high priority one. if bit 11 is set the automatic ecc cleanup is disabled. on parts with system revision indicating periph_rev3 and later the register can be read back from the l2_misc_value register. e xample s tartup c ode to clear the l2 c ache the following code will work on the bcm1250 and BCM1125/h using 4096 sets. it could be optimized for the BCM1125/h to only clear 2048 sets. # save the old status register, and set the kx bit. # this allows 64 bit addressing through xkphys. mfc0 t2,c0_sr or t1,t2,m_sr_kx mtc0 t1,c0_sr # start the index at the base of the cache management # area, but leave the address bit for "valid" zero. # note that the management tags are at 00_d000_0000, # which cannot be accessed through kseg1, # so generate a 64-bit xkphys uncacheable address to get to it. # the phys_to_xkphys mapping adds 9000_0000_0000_0000 to the address dli t0,phys_to_xkphys(a_l2c_mgmt_tag_base) # loop through each entry (4096) and each way (4) li t1,l2c_entries_per_way*l2c_num_ways # write a zero to the cache management register at each # address. align and do four per loop to run faster since the code # is running in uncached space. .align 4 1: sd zero,0(t0) sd zero,cache_line_size(t0) sd zero,2*cache_line_size(t0) sd zero,3*cache_line_size(t0) daddu t0,(4*cache_line_size) # size of a cache line subu t1,4 bne t1,0,1b # # restore old kx bit setting # mtc0 t2,c0_sr j ra # return to caller bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 100 section 5: l2 cache document 1250_1125-um100-r r egisters the l2 tag registers are unpredictable until the first event that causes them to be written. the performance of reads to the registers will be low, while a read is in progress hardware will delay accesses to the l2 cache registers and any registers in the scd. table 56: level 2 cache tag register bits l2_read_tag - 00_1004_0018 l2_ecc_tag - 00_1004_0038 read only 4:0 0 14:5 index 15 tag bit 39 (holds index bit 15 in a 256kb or 512kb cache and is a tag bit in a 128kb cache) 16 tag bit 40 (holds index bit 16 in a 512kb cache and is a tag bit in a 256kb or 128kb cache) 38:17 tag bits 39 0 45:40 tag ecc (raw). 47:46 way 48 dirty 49 valid 59:50 data ecc (raw) 63:60 reserved table 57: level 2 cache settings register bits l2_misc_value - 00_1004_0058 read only sytem revision periph_rev3 and later only 3:0 cache quadrant information [t,b,r,l] (broadcom use only) 7:4 l2_cache_disable register value 8 reads back enable for use of low priority memory blocker from value written as bit [10] in the l2_misc_config register address 9 reads back disable of ecc cleanup from value written as bit [11] in the l2_misc_config register address 13:12 reads back l2_way_enable register 63:14 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 5: l2 cache page 101 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 102 section 5: l2 cache document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 103 section 6: dram i ntroduction the part incorporates a ddr sdram controller that works closely with the level 2 cache to provide a high performance memory system. the bcm1250 memory controller includes two channels each providing a 64 bit data path with 8 bit ecc. the BCM1125/h parts have a memory controller with a single channel providing a 64 bit data path with 8 bit ecc. each channel can directly support up to two standard two physical bank jedec 184 pin ddr dimms (for a total of four dimms on a bcm1250) running at 133mhz clock (266mhz data rate, sometimes called pc2100 dimms based on pc266a parts) and allows for performance to increase as the dimms support higher data rates. in a more controlled electrical environment, with the drams mounted on the main board and traces tightly controlled the memory controller can run up to 200mhz clock giving a 400mhz data rate. the peak memory bandwidth for a single channel using standard (133 mhz clock) dimms is 16 gbit/s and increases up to 50 gbit/s for a high speed (200 mhz clock) design using both channels. the memory controller supports three types of memory all of which use sstl_2 signalling levels and the conventional multiplexed address bus. standard ddr sdram which may be mounted on board or on dimms. standard ddr sgram which can be on dimms but are designed to be mounted on the main board and run with faster cycle times than standard ddr. the memory controller does not make use of any of the graphics features. fujitsu/toshiba/samsung ddr fcram (fast cycle ram) which is designed to be mounted on the main board. these parts have smaller rows and a much simplified command set allowing them to have both faster cycle times and lower access latency than standard ddr. each channel can support up to 1 gbyte of memory using 256 mbit technology parts. as larger drams become available this will increase to 2 gbyte with 512 mbit parts and 4 gbyte with 1 gbit parts (note that gigabit parts that use 14 row address bits are only supported on the BCM1125/h and versions of the bcm1250 supporting periph_rev3 or later). a special large memory mode allows these sizes to be doubled, but requires the use of an external decoder and may be lower performance. a c omment on the term b ank the term "bank" is unfortunately used in a couple of different ways when discussing ddr sdram memory systems. the first use of bank is to describe the organization within a memory device, most devices have four internal banks and thus need two bank address bits (ba[1:0]). the number of banks on a device sets the number of pages that it can have open at a given time. the second use of bank is to describe the physical groups of devices that are enabled by a single chip select. standard ddr 184 pin dimms can have two physical banks and thus need two chip selects. each physical bank corresponds to one load on the data and dqs signal lines. the number of loads on the address lines for a physical bank depends on the organization of the memory devices. for the 64 bit wide data path used by the memory channel using x8 devices gives 8 address loads per physical bank (9 if ecc is used). using x16 devices gives 4 (or 5) loads and using x32 devices gives 2 (or 3) loads. in this chapter the unqualified term bank will only be used to refer to internal banks. physical banks will always be described as such. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 104 section 6: dram document 1250_1125-um100-r m emory c ontroller a rchitecture the memory controller consists of a zbbus interface and one or two memory channel interfaces. the channels on the bcm1250 are numbered 0 and 1, the BCM1125/h only has channel 1. the block diagram is shown in figure 14 on page 105 . the zbbus interface consists of: the request queue (rqq). a data buffer (dbf) for read and write. the scheduler for issuing requests to memory (out-of-order). the request queue (rqq) is a 16 entry shift-register queue. entries are added in-order as requests come from zbbus and are issued out-of-order to the memory channels. any entry in the rqq can be issued to memory. entries in the queue can be reserved for use by network dma, this reduces the latency of reads and improves performance when using slower or highly loaded memory systems. the data buffer (dbf) is also 16 entry and is shared between reads and writes. each entry in the buffer is a full 256 bit block wide. the buffer has multiple pairs of read and write ports; one pair for zbbus which can transfer a full block each access, and a pair for each of the memory ports that transfer 64 bit double words. when a request is received from zbbus, entries are allocated in both the rqq and the dbf. entries are normally added to the rqq in sequential order. however, checks are first done to detect any write to read or write to write address dependencies. the rqq holds the memory access information and initially the dbf is empty. if the request is a write then the request is not ready for submission to the memory until the data has been received from zbbus and written to the dbf, at which time the rqq entry becomes valid for the memory scheduler. both entries are freed when the write request is issued to the sdrams. if the request is a read the rqq entry becomes valid as soon as the l2 cache reports a miss, and the dbf entry is used to stage the data when it returns from memory. in this case the entries are freed when the data is sent on zbbus. the memory controller calculates an ecc during writes, and will check it during reads. this provides correction of all single bit errors and detection of double bit errors. an extra 8 bit ecc bus accompanies the 64 bit data bus, matching the standard 72 bit ddr dimms. ecc checking can be disabled. the memory controller will service uncacheable requests from zbbus. a read-modify-write cycle for the full line is needed for uncacheable writes, merging the new data into the existing block and recalculating the ecc. the additional memory accesses and the poor utilization of the dbf will cause the memory system performance to degrade if many uncacheable accesses are done. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 105 figure 14: memory controller block diagram entries are selected for issue from the rqq based on the state of the other entries and the status returned by the memory pipeline controller for each of the channels. the issues can be out-of-order, and use the following rules: any access to configuration registers causes serialization of the queue. these accesses can be in progress for some time (40-50 zbbus clocks), so should not be done during normal operation. any access with address conflict with an entry already in the queue will be only issued when it reaches the head of the queue. (it can be bypassed by other requests). if priority is enabled in the mc_config_1 register, any read requests from i/o bridge 1 are given priority and are issued in-order. if a read request conflicts with an existing write, the write is also given priority. if a channel is currently doing a read, all reads to that channel will be issued ahead of any writes. if a read has been bypassed enough times to reach its age_limit (see below) it will go ahead of other reads. if a channel is currently doing a write, all writes to that channel will be issued ahead of any reads up to a maximum number of consecutive writes that are set in the channel configuration register. if the open page policy is being used an entry that hits on an open page goes first. if the open page policy is disabled an entry that is to a precharged bank (closed bank) goes first. if a channel is currently idle, reads will be issued before writes. otherwise entries are issued in the order they were allocated. rqq request queue dbf data buffer m-channel1 control m-channel0 control zbbus m-channel1 m-channel0 address/cmd write-data read-data addr/cmd bcm1250 only bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 106 section 6: dram document 1250_1125-um100-r when a channel switches from writes to reads (and back) there is a delay while the data bus lines and timing strobes (dqss) turnaround from the controller driving to the memory driving (or the reverse). to get the best bandwidth from the channel the controller batches writes and reads to minimize the number of these turnaround delays. if the controller is doing reads then any writes get buffered in the rqq. eventually there will either be no new read requests or the rqq will become full of writes, the controller will then only have writes to service and can drain them. since all writes are posted (once they have been sent the sender receives no reply) there is no problem in delaying them in this way. when the controller is performing a write burst any reads will suffer additional latency as they wait in the rqq for the writes to drain. the simple case is that the read is trapped behind all the writes that have been buffered up during the previous read burst. however, since the writes drain the rqq additional writes could be inserted into the queue further delaying the read. to minimize the extra latency a read will suffer during a write burst, the controller counts the number of writes done in the burst and will switch to reads if the burst is longer than the wr_limit (and there are reads waiting). the write limit is set per-channel in the mc_config register. the memory bus utilization can be increased by increasing the limit, the average read latency will be decreased by decreasing the limit. a similar situation arises for a channel that is just doing reads. reads to an open page will be issued ahead of reads to a closed page. once a read is completed the data can be returned and the rqq entry freed. it is therefore possible for more requests to the open page to be added to the queue, these will also bypass the read to the closed page. to limit the length of time the read to the closed page is blocked, the controller limits the number of reads that may pass it. every time a read is bypassed its age is incremented, when it reaches the age_limit no new entries will be permitted to pass it a nd it (and any entries ahead of it) will drain from the queue. the age_limit is set per-channel in the mc_config register. the trade-off is the same as for the wr_limit: the memory bus utilization will be increased by increasing the limit, the average read latency will be decreased by decreasing the limit. reads from i/o bridge 1 can be given priority to ensure timely servicing. in most systems this should be enabled (which is the default) to avoid transmit buffer underruns at high data rates. the low relative frequency of i/o bridge 1 dma requests minimizes the impact of this prioritization on other requests, but ensures that the latency sensitive requests are not delayed behind a high frequency request stream (for example from the cpu or data mover). along with this rqq entries may be reserved for i/o bridge 1 requests. if the number of entries in the queue reaches the limit set in the iob1_qsize field in the mc_config_1 register then all agents apart from i/o bridge 1 will back off from accessing the memory until the number of entries in the queue falls below the iob1_qsize set in mc_config_0 . some hysteresis is provided by having the two limits. the number of buffers that should be reserved depends on the number of active dma channels, their bandwidth, and the amount of other memory activity in the system. for a relatively high load on the system a reasonable staring point is to reserve 5 buffers. note that if zeros are used for the iob1_qsize fields the memory controller performance will be extremely poor. each memory channel interface consists of: the memory pipeline control queue and scheduler (mcq). memory data fifo registers (mfifo). configuration registers (crreg). the mcq keeps track of the activities of the memory cycle, open rows and banks. it supplies this information to the issue logic for the request queue and the memory scheduler. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 107 m emory a ccess s equencing certain applications need more control over the memory access pattern than is available using the normal operations in the memory controller, for example when the memory is being used for transaction logging. the controller was designed to optimize the normal case, but there are several methods that software can use to force the sequence. the ultimate control is to set the force_seq bit in the mc_config register. this forces the controller to send requests to the sdrams in the same order their address phase happens on the zbbus. this prevents most of the memory optimizations and is likely to be low performance. in many cases a memory barrier operation is sufficient. this can be provided by an access to the memory controller configuration registers. an access to one of the channel registers will force all reads/writes ahead of it to complete before any behind it. in the normal case a cpu doing a write of a to address 1 followed by a write of b to address 2 provides no guarentee that a gets written into the sdram before b. however, if the cpu performs a write of a to address 1 followed by a write of 0 to the mc_test_ecc register and finally the write of b to address 2 then a is always written to memory before b. all these operations are posted, so the cpu has no way of knowing when they complete. if the cpu needs to both place a memory barrier and be informed of the completion then a read may be done to one of the controller configuration registers. if the cpu performs a write of a to address 1 followed by a read of the mc_test_ecc register and finally a write of b to address 2 then a is always written to memory before b and when the cpu sees the result of the read it knows that a will have been written to the sdram (but b may still be in the queue). a sync instruction or use of the read result can be used to stall the cpu until the read completes. c lock r atios and c locking s cheme the memory clock range is from 133 mhz - 200 mhz produced by dividing down the zbbus clock, which is half the cpu core frequency. the ratio of the clocks can be set from 1:2 to 1:4.5 in steps of 0.5, by programming the channel configuration register. the channels may run at different speeds. table 58: clock speed cpu clock zbbus clock memory clock 4.5:1 memory clock 4:1 memory clock 3.5:1 memory clock 3:1 memory clock 2.5:1 memory clock 2:1 1200 600 133.3 150.0 171.4 200.0 240.0 300.0 1150 575 127.8 143.8 164.3 191.7 230.0 287.5 1100 550 122.2 137.5 157.1 183.3 220.0 275.0 1050 525 116.7 131.3 150.0 175.0 210.0 262.5 1000 500 111.1 125.0 142.9 166.7 200.0 250.0 950 475 105.6 118.8 135.7 158.3 190.0 237.5 900 450 100.0 112.5 128.6 150.0 180.0 225.0 850 425 94.4 106.3 121.4 141.7 170.0 212.5 800 400 88.9 100.0 114.3 133.3 160.0 200.0 750 375 83.3 93.8 107.1 125.0 150.0 187.5 700 350 77.8 87.5 100.0 116.7 140.0 175.0 650 325 72.2 81.3 92.9 108.3 130.0 162.5 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 108 section 6: dram document 1250_1125-um100-r table 58 shows possible memory clock frequencies for different divide ratios and cpu clock speed. table 59 shows the percentage difference for the closest frequency below some common dimm frequencies for each of the cpu clock speeds (entries are left blank if the closest frequency is more than 10% under the required one) 600 300 66.7 75.0 85.7 100.0 120.0 150.0 550 275 61.1 68.8 78.6 91.7 110.0 137.5 500 250 55.6 62.5 71.4 83.3 100.0 125.0 450 225 50.0 56.3 64.3 75.0 90.0 112.5 400 200 44.4 50.0 57.1 66.7 80.0 100.0 table 58: clock speed (cont.) cpu clock zbbus clock memory clock 4.5:1 memory clock 4:1 memory clock 3.5:1 memory clock 3:1 memory clock 2.5:1 memory clock 2:1 table 59: percent deltas from popular dimm frequencies cpu clock zbbus clock 133 mhz dimm clock 143 mhz dimm clock 166 mhz dimm clock 183 mhz dimm clock 200 mhz dimm clock 1200 600 0.0 -6.8 -10.0 -6.5 0.0 1150 575 -4.1 - -1.4 - -4.2 1100 550 -8.3 -3.8 -5.7 0.0 -8.3 1050 525 -1.5 -8.2 -10.0 -4.5 - 1000 500 -6.2 -0.1 0.0 -9.1 0.0 950 475 - -5.1 -5.0 -5.0 900 450 -3.5 -10.1 -10.0 -1.8 -10.0 850 425 -8.9 -0.9 - -7.3 - 800 400 0.0 -6.8 -4.0 - 0.0 750 375 -6.2 - -10.0 - -6.3 700 350 - -2.1 - -4.5 - 650 325 -2.5 -9.1 -2.5 - - 600 300 -10.0 - -10.0 - - 550 275 - -3.8 - - - 500 250 -6.2 - - - - 450 225 - - - - - 400 200 - - - - - user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 109 m emory c onfigurations before the first sdram access starts, the memory configuration registers must be initialized, and the correct startup sequence issued to the memory chips. this is normally done by the bootrom code. the broadcom cfe firmware includes memory controller initialization which uses the serial presence detect (spd) eeprom information to support a wide range of memory types. this code provides the best starting point for memory initialization. m apping the physical address space is mapped to memory address space. the physical address map has four 256 mbyte regions and one expanded 508 gbyte region of the address space allocated to the memory controller. the memory controller will map the four 256 mbyte regions into a single contiguous 1 gbyte region of memory address space for use by the memory channels. memory address space is only used in the configuration of the memory controller. the constraints on the physical memory map of the part (see section: ?memory map? on page 34 ) caused the main memory address ranges in the low 4gb of the address space to be allocated in non-contiguous blocks. however, the memory controller configurations are more flexible if it sees them as a single contiguous block. for example, consider a system where the actual memory consists of one single physical bank (i.e. only one chip select) 512 mb dimm. since there is only one chip select this must be configured to have a single address range. but the physical address map has one 256 mb memory block starting at zero (which contains the cpu exception vectors and must be present) and the next 256 mb block starts at 00_8000_0000 . if the memory controller used physical addresses there would not be a way to configure the address range to use the whole dimm. however, in memory address space the two memory blocks can be made contiguous and the dimm can be configured. the mapping for the four physical address ranges that have zero for the upper eight bits is configured in the channel configuration register. they can be mapped into the first four 256 mb blocks of the memory address space. the default mapping is shown in table60onpage109 . there is normally no need to change from the defaults. c hannel s elect on the bcm1250 the two channels may be interleaved or they may be independent. if they are interleaved then they must match in all parameters. when they are interleaved a single address bit is used to select between them. when the channels are independent the start and end address set for the chip select generation will also select between the two channels. table 60: mapping physical address to memory controller address physical address space (used to access the memory) memory address space (used to configure the controller) size 00_0000_0000 - 00_0fff_ffff 00_0000_0000 - 00_0fff_ffff 256 mb 00_8000_0000 - 00_8fff_ffff 00_1000_0000 - 00_1fff_ffff 256 mb 00_9000_0000 - 00_9fff_ffff 00_2000_0000 - 00_2fff_ffff 256 mb 00_c000_0000 - 00_cfff_ffff 00_3000_0000 - 00_3fff_ffff 256 mb 01_0000_0000 - 7f_ffff_ffff 01_0000_0000 - 7f_ffff_ffff 508 gb bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 110 section 6: dram document 1250_1125-um100-r c hip s elect a memory controller channel has four active low chip selects:cs[3:0]. the address range that they become active for is configurable. on the bcm1250 if the two channels are interleaved then the chip selects for each channel are programmed to an identical address range, which is twice the size of the memory attached to one of the channels. within a channel there are three methods for generating the chip selects: interleaved-cs, msb-cs and mixed-cs. msb-cs divides the memory space into contiguous or non-contiguous sub-spaces based on address ranges. the start and end address for each select line is individually programmable. for example cs[3] covers the top portion of memory space and cs[0] covers the bottom portion.the memory size covered by each cs can be different. interleaved-cs decodes the chip select from two non-msb memory address bits, for example the lower column bits or the lower row bits. this increases the possibilities for having active banks. in this configuration the channel must be assigned a contiguous memory address range and each chip select covers the same memory size. mixed_cs allows interleaving between a pair of chip se lects (either cs[0] and cs[1], or cs[1] and cs[2], or cs[2] and cs[3]) and allows the others to be set using their start and end registers. this mode allows devices to be interleaved when only two chip selects are in use. figure 15: chip select options figure 15 on page 110 shows some chip select options. on the left msb_cs is used to separate the four chip selects into different regions. the diagram in the center shows a full interleaved_cs, which requires all the chip select regions are the same size. on the right mixed_cs has the sdrams on chip select 0 and 1 interleaved and keeps the sdrams on chip select 2 and 3 separate. for the memory covered by chip selects 0 and 1 there can be twice as many active banks (although there maybe a chip-to-chip bubble on some accesses). 3 2 1 0 3 2 1 0 3 2 1 0 3 2 1 0 1 0 1 0 1 0 3 2 1 0 3 2 1 0 msb_cs (can have all cs different size) mixed_cs 0 and 1 interleaved (cs 0 and 1 same size) interleaved_cs (all cs same size) user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 111 the address range covered by each of the chip selects is set in the mc_cs_start and mc_cs_end registers. the start address register holds addre ss bits [39:24] that when extended with zeros in bits [23:0] give the lowest address in the range. the end address register holds address bits [39:24] that when extended with zeros in bits [23:0] give the first address above the range. the comparison is done after addresses have been translated from physical addresses to memory addresses (see section: ?mapping? on page 109 ). if two chip select regions are interleaved (mixed_cs mode) their start address registers must be set to the start of the common range, and their end address registers are set to the end address of the common range plus 1 (i.e. they are programmed identically, to a range twice the size of one of them). the address bit that selects between the two chip selects is configured by writing a single one in that bit position of the mc_cs_interleave register. if all four chip select regions are interleaved (interleaved_cs mode) their start address registers must be set to the start of the common range, and their end address registers are set to the end address of the common range plus 1 (i.e. they are programmed identically, to a range four times the size of one of them). the address bits that selects between the two chip selects is configured by writing two ones in adjacent bit positions of the mc_cs_interleave register. if a chip select is not used its start and end address should both be set to zero. if the two channels are interleaved then the chip select region sizes will be doubled and must be identical for both channels. if a request is received by the memory controller that does not match in any of the chip select regions no sdrams will be selected. on writes the data will be discarded. on reads the memory controller will terminate the cycle by reading unpredictable data. the controller can be configured to return either a bus error or a valid data flag with the data. in normal operation the bus error would be used to signal that a bad memory address was used. during system testing and sizing it may be useful to have the controller always return valid data. the controller will not hang during an access with no chip select asserted. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 112 section 6: dram document 1250_1125-um100-r e xample c hannel and c hip s elect c onfigurations configuring the memory map for channels and chip selects is usually straightforward, but there are a few special cases. in this section some example configur ations are presented. the values that are set for chip select start and end addresses are shown in the figures, these represent bits [39:24] of the address. the simplest memory system uses a single chip select on a single channel. using 256mb memory technology a memory system could be built using 4 16mx16 memory chips (5 if ecc is required) to give a total of 128mb of memory. figure 16 shows how this could be configured. the standard mapping from physical to memory addressing is used, although only the first sdram region is needed for 128mb from physical address 00_0000_0000 to 00_07ff_ffff . this maps to the same address in memory space. the controller chip selects are all disabled apart from channel 0 chip select 0 which is set with start and end to cover this range. any reads to the space that is not configured will result in a bus error or unpredictable data being returned depending on the setting of the berr_disable bit in the mc_config register. figure 16: example single channel 128mb using the 512mb memory technology and using 8 (or 9 with ecc) 64mx8 allows each chip select to have 512mb of memory. two physical banks will therefore allow a 1gb memory system to be built. there are three interesting configurations (two on the BCM1125/h). in these advantage is taken of the memory address space collapsing the configuration range into a contiguous space. in the physical address space the cpu and dma engines use the 1gb is split up into four 256mb chunks, but in the actual memory there are just two 512mb physical banks. the translation into memory address space pulls the four physical address regions into a single 1gb chunk. in the simplest configuration this can be split in two and allocated to chip selects. channel 0, chip select 0 bank2_map bank1_map bank0_map expansion space physical address (used by cpu and dma) mc address space (only used for mc configuration) 00_0000_0000 00_1000_0000 00_8000_0000 00_9000_0000 00_a000_0000 00_c000_0000 00_d000_0000 01_0000_0000 80_0000_0000 ff_ffff_ffff first sdram peripherals second sdram third sdram reserved fourth sdram peripherals/l2 mgmt sdram expansion ht this range cannot be accessed bank3_map direct map cs0_start=00_00 cs0_end=00_08 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 113 figure 17 shows the first configuration. this configuration has chip select 0 for the low half and chip select 1 for the upper half and the start and end addresses of their range are set to reflect this. figure 17: example 1gb with two chip selects on one channel channel 0, chip select 0 bank2_map bank1_map bank0_map expansion space physical address (used by cpu and dma) mc address space (only used for mc configuration) 00_0000_0000 00_1000_0000 00_8000_0000 00_9000_0000 00_a000_0000 00_c000_0000 00_d000_0000 01_0000_0000 80_0000_0000 ff_ffff_ffff first sdram peripherals second sdram third sdram reserved fourth sdram peripherals/l2 mgmt sdram expansion ht this range cannot be accessed bank3_map direct map cs0_start=00_00 cs0_end=00_20 channel 0, chip select 1 cs1_start=00_20 cs1_end=00_40 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 114 section 6: dram document 1250_1125-um100-r figure 18 is an alternative that uses chip select interl eaving to (on average) increase the number of active banks. notice the chip select ranges are now the same for both selects. figure 18: example 1gb with two chip selects interleaved on one channel on the bcm1250 there is a higher performance possibility. rather than putting both physical banks on the same channel one can be put on each channel. this doubles the number of data bits in use (since the controller can run both channels in parallel), allowing twice the peak bandwidth. channel 0, chip select 0 bank2_map bank1_map bank0_map expansion space physical address (used by cpu and dma) mc address space (only used for mc configuration) 00_0000_0000 00_1000_0000 00_8000_0000 00_9000_0000 00_a000_0000 00_c000_0000 00_d000_0000 01_0000_0000 80_0000_0000 ff_ffff_ffff first sdram peripherals second sdram third sdram reserved fourth sdram peripherals/l2 mgmt sdram expansion ht this range cannot be accessed bank3_map direct map cs0_start=00_00 cs0_end=00_40 channel 0, chip select 1 cs1_start=00_00 cs1_end=00_40 cs_interleave=bit7, cs_mode=mixed user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 115 figure 19 shows this, with the interleave on a relatively low address bit. notice that again the chip select ranges are the same for both selects, but in this case they are for different channels. figure 19: example 1gb with two chip selects interleaved across both channels these examples have benefited from the memory address space map having a contiguous 1gb range. additional memory could be added in the expansion space. however, there are some configurations that require a 2gb chip select region. for example if the configurations used in figure 17 - figure 19 were upgraded to use 1gb memory technology (rather than 512 mb) the size will double. the same effect will be seen if two additional physical banks are added and 4-way chip select interleave used in the single channel case or channel and chip select interleaving used in the dual channel case. systems using the big memory mode (see section: ?larger memory systems? on page 124 ) will also face this issue even when using lower density memory parts. the 2gb problem can be solved with a little help from software. the hardware is configured in a way that creates an alias of the low 1gb of memory which software should ensure is never used (for example by the virtual-physical address translation in the tlb). rather than creating a 2gb chip select range, the chip selects are programmed for a 6gb range and address bits [32:31] are not selected for use as a row, column or bank address. thus the real 2gb range appears 3 times in the range given to the chip selects. channel 0, chip select 0 bank2_map bank1_map bank0_map expansion space physical address (used by cpu and dma) mc address space (only used for mc configuration) 00_0000_0000 00_1000_0000 00_8000_0000 00_9000_0000 00_a000_0000 00_c000_0000 00_d000_0000 01_0000_0000 80_0000_0000 ff_ffff_ffff first sdram peripherals second sdram third sdram reserved fourth sdram peripherals/l2 mgmt sdram expansion ht this range cannot be accessed bank3_map direct map cs0_start=00_00 cs0_end=00_40 channel 1, chip select 0 cs0_start=00_00 cs0_end=00_40 channel_sel=bit7 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 116 section 6: dram document 1250_1125-um100-r in figure 20 it can be seen that 3gb of the aliases are hidden in the memory address space that cannot be accessed from the physical space. the only alias that needs to be considered is the 01_0000_0000 - 01_3fff_ffff alias of 00_0000_0000 - 00_3fff_ffff. a particular memory location must be accessed through only one of these ranges or the coherency algorithm will break down. the cpu exception vectors are all at the bottom of memory so in most systems the 00_0000_0000 - 00_3fff_ffff space will be used. some systems may choose to use 00_0000_0000 - 00_1fff_ffff (accessible through kseg0) and 01_2000_0000 - 01_3fff_ffff to keep the upper range contiguous with the second 1gb -- however this only allows dma access to the low 256mb from the pci (or from 32-bit addressing peripherals bridged from the ht interface) since the dma and cpu accesses must use the same physical range. (pci accesses translated by the bar0 map could be used.) figure 20: example 2gb with two chip selects interleaved on one channel channel 0, chip select 0 bank2_map bank1_map bank0_map expansion space physical address (used by cpu and dma) mc address space (only used for mc configuration) 00_0000_0000 00_1000_0000 00_8000_0000 00_9000_0000 00_a000_0000 00_c000_0000 00_d000_0000 01_0000_0000 80_0000_0000 ff_ffff_ffff first sdram peripherals second sdram third sdram reserved fourth sdram peripherals/l2 mgmt sdram expansion ht bank3_map alias of bank0-3 cs0_start=00_00 cs0_end=01_80 channel 0, chip select 1 cs1_start=00_00 cs1_end=01_80 cs_interleave=bit7, cs_mode=mixed_cs 01_4000_0000 01_8000_0000 should not be used address bit 32 is not mapped to sdrams alias of bank0-3 upper 1gb alias of upper 1gb alias of upper 1gb user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 117 r ow , c olumn and b ank c onfiguration the memory channel can be structured in many different ways with many different types of sdrams on different types of dimms and different dimm counts per memory channel. in order to support such different configurations, the assignment of the address bits for row, column, and internal bank selection are fully software configurable along with the sdram timing parameters and operating modes. each memory channel is 8 bytes (64 bits) wide with ecc (8 bits), so the three lowest physical address bits play no part in the memory addressing. the memory controller always accesses memory with a burst of four 64-bit double-words, to access a full cache line. therefore bits [4:3] of the physical address are always used as the lowest two column address bits. (the sdrams count the burst internally, so the memory controller only ever drives 00 on these two bits.) table 61 shows the maximum number of address bits that can be used for the row, column and bank parts of the sdram address. each of the memory channels can theoretically address 4gb of memory (for a total of 8gb attached on a bcm1250). this comes from the number of ras (13 or 14), cas (12 or 11), bank (2), chip select (2) and bytes in dword(3) = 32 address bits per channel. (the gigabit sdrams are mostly configured with 14 row and 11 column address bits, to support these the extra a13 pin was added in periph_rev3 of the bcm1250 and on the BCM1125/h.) however, there are only four chip selects (hence the 2 bit equivalent shown above) per channel, and four bit wide devices are not supported. the maximum size is therefore achieved using four physical banks of 8 (or 9 with ecc) eight bit wide devices. using 256mb technology parts this limits the total size to 1gb per channel or 2gb total. using 512mb parts this doubles and will double again when the 1gb ddr parts come out (reaching the theoretical maximum of 8gb). the memory controller can use fast ddr parts (200 mhz clock). to work at this speed the signal trace lengths between the controller and the memory devices must be carefully controlled, maintaining tight tolerances and avoiding long stubs. using a carefully chosen termination scheme dimms may be run at this speed. table 61: address bits used by a memory channel dram address selected from comment row address[13:0] row address[14:0] (fcram) contiguous block of bits from address[34:10] regular sdrams have 13 row address bits (or 14 on BCM1125/h and bcm1250 periph_rev3 or later). fcrams use we_l and cas_l as extra row bits. column address[1:0] fixed to use address[4:3] using 256 mb technology parts only maximum of 10 column bits are used. for larger devices the jedec standard requires that the column address is presented on a[12:11,9:0] retaining the use of a10 as the auto pre-charge bit. column address[12:11, 9:0] one or two contiguous blocks of bits from address[20:7] and address[6:5] bank address[2:0] contiguous block of bits from address[36:5] regular sdrams have only two bank address bits, so only two bits should be set. if three bits are set for bank address the top address bit becomes ba[2] and is not used for row or column. the top address bit is: a[12] for sdram when the ram_with_a13 bit is clear a[13] for sdram when the ram_with_a13 bit is set a[14] for fcram chip selects (4) address range decode or cs interleave selection only one chip select will be active (low) during an access. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 118 section 6: dram document 1250_1125-um100-r section: ?larger memory systems? on page 124 describes a mode of the memory controller that allows external generation of eight chip selects rather than four. this mode does not increase the theoretical maximum size of the memory, but it does double the maximum achievable size for the 256 mb and 512 mb parts. however, the address loading may require the use of registered dimms, the data loading will limit the maximum clock speed and there are limits on the supported memory configurations because the controller acts as if only two chip selects are in use. the controller is programmed per chip select to determine the address bits used to generate the bank, row and column address bits sent to the sdram. the row and column address size depends on the devices used. the controller is programmed with bit masks that are applied to the memory address to extract the bank, row and column address. bits are set in the mask to indicate the corresponding address bit should be used. the bank address is normally two bits corresponding to the ba[1:0] pins on the controller. if three bits are set in the bank address mask the controller will use the topmost addre ss bit (a[12] for regular sdram, a[14]/cs[3] for fcram) as an extra bank bit and will work with 8 bank parts. with two exceptions described below, the set bits in the masks must be contiguous, so the right-most bit sets the lowest bit used and the number of set bits should match the number of address bits needed by the device. example masks are shown in table 62 . the bank is selected from the lowest bits, the column next and the row from the upper bits. note that the column masks need not have bits [4:3] set, these address bits are always used as the low column bits. one problem with this example is that the internal bank is switched every cache line, so streaming data that transfers in 64 byte blocks (for example hypertransport reads or dmas to the macs) will not make good use of open pages in the sdram. the interleaving for banks (or chip selects or channels) is likely to work better with a larger block. the two exceptions to the rule that the masks must be contiguous allow for this. the column mask may be split so that bit 5 or bits [6:5] may be set in addition to the contiguous bits. this allows for the interleave to be on 64 or 128 byte chunks. changing the example to use 64 byte blocks gives the masks shown in table 63 , and using 128 byte blocks gives the masks in table 64 . this example only shows interleaving the internal banks of a single device, if there were chip select or channel interleaving there would be more than two zeros separating the set bits in the column mask. table 62: example for 128 mbyte cs region with 4k rows, 1k columns row address bits [26:15], column address bits [14:7,4:3], bank address bits [6:5] row 00000000_00000111_11111111_10000000_00000000 column 00000000_00000000_00000000_01111111_10000000 bank 00000000_00000000_00000000_00000000_01100000 table 63: example for 128 mbyte cs region with 4k rows, 1k columns, 64 byte interleave row address bits [26:15], column address bits [14:8,5,4:3], bank address bits [7:6] row 00000000_00000111_11111111_10000000_00000000 column 00000000_00000000_00000000_01111111_00100000 bank 00000000_00000000_00000000_00000000_11000000 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 119 the previous examples show interleaving between t he banks within a device. it is also possible to use interleave between chip selects on a channel. this is done by setting an appropriate mode in the mc_config register. if there are two chip selects available on a channel (i.e. there are two physical banks of memory of the same size) then the mixed_cs mode can be used to allow them to be interleaved. when this mode is set the mc_cs_interleave register can have a single bit set to program which bit of the address is used to switch between chip selects. table 65 gives an example of this, the same 128 byte interleave is done between banks on the same device, but the upper row and column bits have been moved to allow for switching between the devices on the channel using bit [9]. if there are four physical banks of memory then the interleave_cs mode can be used to allow a full interleave between the physical banks. this is shown in table 66 . table 64: example for 128 mbyte cs region with 4k rows, 1k columns, 128 byte interleave row address bits [26:15], column address bits [14:9,6:5,4:3], bank address bits [8:7] row 00000000_00000111_11111111_10000000_00000000 column 00000000_00000000_00000000_01111110_01100000 bank 00000000_00000000_00000000_00000001_10000000 table 65: example for 256 mbyte region with 4k rows, 1k columns, two cs, and 128 byte interleave row address bits [27:16], column address bits [15:10,6:5,4:3], bank address bits [8:7], mixed_cs selected by bit [9] row 00000000_00001111_11111111_00000000_00000000 column 00000000_00000000_00000000_11111100_01100000 bank 00000000_00000000_00000000_00000001_10000000 cs interleave 00000000_00000000_00000000_00000010_00000000 table 66: example for 512 mbyte region with 4k rows, 1k columns, four cs, and 128 byte interleave row address bits [27:17], column address bits [16:11,6:5,4:3], bank address bits [8:7], interleaved_cs selected by bit [10:9] row 00000000_00011111_11111110_00000000_00000000 column 00000000_00000000_00000001_11111000_01100000 bank 00000000_00000000_00000000_00000001_10000000 cs interleave 00000000_00000000_00000000_00000110_00000000 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 120 section 6: dram document 1250_1125-um100-r combining the bank, row and column masks with the chip select selection allows for more complicated mixing on a single channel. table 67 shows a configuration using 128 mbyte single chip select dimm on chip select 0, and a 128 mbyte dual chip select dimm (also called a two bank dimm using the term bank to refer to the physical banks) on chip select 1 and 2. mixed-cs mode is used to allow the first dimm to be standalone and the other to be interleaved. in this case the switch between the two physical banks is made based on address bit 15, so the full column addressed page is contiguous in the address space. c hoosing i nterleave p arameters the best method of interleaving the memory is highly system dependant, so there is no single rule about how the memory controller should be configured. however, there are some general guidelines that give a starting point. the general goal is to maximize the number of banks (internal and physical) of the memory that are in use, which in turn leads to more overlap of transactions and less unused time on the channels. there are different costs involved in switching between banks: if the driver of the databus switches from one device to another (a change in physical banks) there must be an additional turnaround cycle which is not needed for a bank to bank switch in the same device (a change in internal banks). there are several measurable parameters: memory bandwidth and average access latency are normally the most important, but maximum access latency may also be important. some things (e.g. a faster memory clock) will improve all of them, but many of the options improve one at the expense of others. in particular reductions in average memory latency are often at the expense of increasing the maximum latency. in most cases the system will use more than one physical bank of memory. these can be put on different chip selects on the same channel or on the different channels. from a performance standpoint using both memory channels is almost always the correct choice. the peak memory bandwidth increases because the two channels have physically separate data buses and operate independently of one another. in some cases using both channels may not be possible on the bcm1250 (for example if the system has a single dimm slot then a two physical-bank dimm is necessarily on a single channel), but both channels should be used if possible (to continue the example: a second dimm slot should go on the other channel in preference to using the remaining two chip selects of the first channel). on the BCM1125/h, two dimm slots with two physical-bank dimms should be used if possible and full chip select interleaving should be enabled. table 67: example for 128 mbyte + 64 mb + 64 mb mixed_cs mode cs0 row bits [26:15], column bits [14:9,6:5,4:3], bank bits [8:7] row 00000000_00000111_11111111_10000000_00000000 column 00000000_00000000_00000000_01111110_01100000 bank 00000000_00000000_00000000_00000001_10000000 cs1,2 row bits [26:16], cs interleave bit [15], column bits [14:9,6:5,4:3], bank bits [8:7] cs interleave 00000000_00000000_00000000_10000000_00000000 row 00000000_00000111_11111111_00000000_00000000 column 00000000_00000000_00000000_01111110_01100000 bank 00000000_00000000_00000000_00000001_10000000 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 121 the simple configuration with two channels each with one physical bank of memory provides a good illustration of the trade-offs involved. the most straightforward way to assign the channels is to have one cover address 0 to n-1 and the other address n to 2n-1. however, most of the time there is a reasonable degree of locality (for example, it is likely that the program and its data will reside entirely in the first n locations of memory) so all activity is going to a single channel -- the effective memory bandwidth has been halved and the access latency will increase because of contention for the channel. in some systems this may be desirable, the second channel will have a lower and more deterministic access latency since it is so lightly loaded. but this gain has come at a very large cost to the system performance as a whole. at the other extreme the channels could be interleaved every cache line. this seems a good choice since the distribution of accesses is likely to be equal across even and odd cache lines, so both channels will be equally used. but since a contiguous access (e.g. a packet streaming in or out of the system) will f lip back and forth between the two channels there is less likelihood that good use can be made of open pages in the memory. a good compromise is to interleave every four cache lines. note that the argument of the previous paragraph will also apply to packet buffers. dedicating one channel to packet buffers and one to the program and associated data will quite often result in the packet buffer channel (which has cpu accesses as well as inbound and outbound dma) being very heavily used and the other channel (which will only be used on accesses that miss in both the l1 and l2 caches) being under-used. in this case the network traffic is limited to half the memory bandwidth and will incur latency associated with using a busy channel. the system performance will be improved by interleaving the channels and thus removing the hot spot and allowing the bandwidth to be shared more evenly. a good general starting point applies the principle from the previous examples: keep a few cache lines contiguous to allow for page mode accesses, then use low bits to interleave across the two channels, the internal banks within a device, and the physical banks (chip selects) on a channel. using the low bits make it likely that even over short periods of time there is a reasonably even distribution of accesses across the regions. the address is therefore broken up as: this format can be used to set the mask bits. 1 the bottom 3 bits are ignored and should be set to zero. the next two bits ( cc ) are also ignored, but are always used as column bits, so they must be considered when the total number of column bits in the device is checked. 2 the next two bits are used for column interleave. for 32-byte blocks (and no column interleave), do not use any column bits here. for 64-byte blocks, use one column bit here, and for 128 byte blocks use two column bits here. these bits will be set in the mc_cs n _col registers. 3 as discussed above, the next bit is a good one to use for interleaving between the two channels. this bit number is assigned in the mc_config register. 4 the next bits are used to select the bank within a memory device. most devices have four banks, so two bits will be set in the mc_cs n _ba registers. 5 when interleaving across physical banks on a channel via chip-selects one or two bits must be set in the mc_cs_interleave register. if there are only two physical banks then mixed_cs mode will be used and one bit set, if there are four physical banks then interleaved_cs mode is used and both interleave bits are needed. 6 the remaining column bits are set in the mc_cs n _col registers. these must be contiguous and the number of bits set will be the number of column address bits needed minus the number set in steps (1) and (2). 7 the remaining address bits form the row address in the mc_cs n _row registers. the number of bits should match the number of row address bits needed by the memory device. rrrr...r cccc...c nn bb p cc cc000 76 5 4 321 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 122 section 6: dram document 1250_1125-um100-r this will give a good starting point and should give acceptable results in most systems. modifications can then be made as a result of performance monitoring. p age p olicy the memory controller supports page mode access to the ddr sdrams, and provides several different policies for controlling page accesses. the fcrams do not support page mode (they always auto-precharge following cas). the closed page policy is the simplest. pages are always closed by using cas cycles with autoprecharge. if the memory uses fcrams the controller must be configured to use this policy. the cas time check policy will check the request queue just before the cas cycle is issued to a channel. if there are requests in the queue that hit on the page then it is left open (and the same test will be performed when the new request is serviced) otherwise it is closed by issuing the autoprecharge command along with the cas. if a sequence of accesses are done to the same page there is a good chance the page will be open when required. the hint based policy is the same as the cas time check, except that it accepts a hint with each memory request. the hint is part of the command on the zbbus, and will be asserted by the dma engines, pci and hypertransport interfaces when doing block moves. if the hint is set on a request then even if there are no more requests the page is left open following its cas time check. if the hint is clear for the request then the behavior matches the cas time check policy. pages that are left open by hints will be closed by subsequent accesses that have the hint clear and fail the cas time check, or will be closed using an explicit precharge instruction if a page conflict occurs to the same bank. the open page policy leaves the page open until a page conflict occurs to the same bank or an autorefresh is done. in the case of a page conflict an explicit precharge command is performed to close the open page, delaying the ras cycle to open the new page. the page policy is set per chip select, allowing different areas of memory to have different policies. the optimal policy can therefore be selected based on the data access patterns. a good starting point is to use the cas time check policy with hints enabled. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 123 s upported dram s and dimm s ddr sdrams the memory controller supports standard jedec ddr sdrams in x8 and x16 configurations, and also the x32 ddr sgrams. in addition the fcrams are supported in both x8 and x16 configurations. the x32 sgram parts only use one dqs signal to cover all 32 data bits, the dqs from the dram should be connected to the corresponding four dqs pins on the controller (m_dqs[7:4] for the upper word and m_dqs[3:0] for the lower word); the controller will only drive on one of the lines but needs to receive on all of them. x4 configuration parts are not supported since the interface has insufficient dqs signals. if the memory channel is configured for sgrams the a10 and a8 signals may need to be swapped. the memory controller follows the ddr standard and puts the autoprecharge flag on the a10 address bit, but many sgrams need it on a8. (in parts with system revision indicating periph_rev3 or greater the pre_on_a8 bit can be set in the mc_drammode register to cause the controller to put the autoprecharge flag on a8 instead of a10.) non-standard 8 bank ddr sdrams use a[12] as the third bank address bit, 8 bank fcrams use a[14] as the third bank address bit. this is enabled if three bits are set in the bank address selection register. for regular sdrams if the ram_with_a13 bit is set in the mc_drammode register the ba[2] is brought out on the a13 pin and a12 reverts to being a row address. ddr fcrams memory channels can be configured to use fcrams. these require two extra row address bits and use a function (fn) flag to distinguish between a read and write access. the jedec defined footprint for standard ddr and fcram parts are identical with the exception of pins 21, 22, and 23. on a ddr sdram these pins are we#, cas#, and ras#, respectively. on the fcram, they become a14, a13, and fn (effectively we#). the bcm1250 or BCM1125/h uses the same mapping when a channel is configured for fcram use, so: mn_we_l becomes mn_a[14] for fcram. mn_cas_l becomes mn_a[13] for fcram. mn_ras_l becomes mn_fn for fcram. mn_cke is called mn_pd_l but is the same. this allows the standard footprint to be used and either type of memory populated. the fcram parts generally have a cas to write data latency that is one less than the cas latency, this is supported by setting the tcwd parameter in the sdram timing register. table 68: supported sdrams ddr sdrams technology size (row x col) size (row x col) jedec std (4 bank) 64 mb 8mx8 (4k x 512) 4mx16 (4k x 256) 128 mb 16mx8 (4k x 1k) 8mx16 (4k x 512) 256 mb 32mx8 (8k x 1k) 16mx16 (8k x 512) non-std (8 bank) 64 mb 2mx32 128 mb 4mx32 256 mb 8mx32 fcram (4 bank) 256 mb 32mx8(32k x 256) 16mx16(32k x 128) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 124 section 6: dram document 1250_1125-um100-r the fcram includes a write mask or variable write (vw) function. the memory controller always does a full burst write and will set the bits accordingly (a[14:11] = 4'b1010 during lal command). dimms all standard ddr sdram dimms of 64+8bit data path are supported, except those that use x4 parts (which replace dm pins with extra dqs pins). both regi stered and unbuffered dimms can be used (for registered dimms the timing parameters must be adjusted to take account of the additional cycle for the latch on the address and command lines). the controller provides four chip selects per channel, allowing two dimm slots that use dual physical bank modules (i.e. need two chip selects) or four dimms with single physical bank modules (each using a single chip select). software should read the dimm configuration information and program the memory controller accordingly. on a single channel it is not possible to mix registered and unregistered dimms. l arger m emory s ystems the memory controller can support larger memory systems by externally decoding 8 chip selects per channel. this may limit the maximum speed of the memory and reduces the number of available configurations. the increased loading requires use of registered dimms in the large memory system. this mode is enabled by setting the large_memory bit in the dram type field of the mc_drammode register. application note 1250- an600-r ?bcm1250 big memory system? describes the design and implementation of a board using the large memory extension. the extension works by configuring the memory controller to only use two chip selects, and driving two additional address bits on the other two chip select out puts. externally each of the chip selects is used to enable a 2-to-4 decoder to generate the actual chip selects for the physical memory banks (the delay through the decoder must be taken in to account when timing analysis is done, but since the chip select signals will be registered on the dimm this should not be a critical timing parameter). internally the memory controller accounts for the switch of chips when the decoded chip select changes, but it only keeps track of the standard four open pages for the two internal chip selects (potentially degrading performance by not making use of open pages). the external connections are: m_cs_l[0] and m_cs_l[1] are the two chip select lines. they should be connected to the active low enable input of the two halves of a dual 2-to-4 decoder. m_cs_[[3:2] provide two additional address bits to qualify the chip selects. they should be connected to the address inputs of the 2-to-4 decoder the (active low) outputs of the 2-to-4 decoder provide 8 chip selects for drams. the internal configuration should be: the full address space should be covered using the mc_cs0 and mc_cs1 address selection registers. the mc_cs2_start , mc_cs2_end , mc_cs3_start and mc_cs3_end registers must all be set to zero. two additional row address bits (corresponding to row_addr[14:13]) should be set in the mc_cs0_row and mc_cs1_row registers. these address bits will be output on the m_cs_l[3:2] pins to qualify the chip select. note that these bits must come from the memory address bits [34:28]. the large_memory bit in the mc_drammode register should be set. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 125 initialization of the drams must be done before the large_memory bit is set. it must be done for each of the real chip selects by stepping through the eight patterns of the chip select field in the mc_drammode register. (note that setting a bit in the chip select field will assert the active low external signal, so to cover all eight external chip selects {cs3,cs2} should count through the four values with {cs1,cs0} set to both 2'b01 and 2'b10.) if the large memory mode is used with parts that use fourteen row address bits (i.e. that need a13) then the ram_with_a13 bit must be set in the mc_drammode register, this causes bits [15:14] from the row address mask to be passed to cs[3:2] rather than bits [14:13]. the page policy should be set to always close page or cas-time-check. memory accesses will have unpredictable results if other page policies are used. the refresh rate should be set in the usual way based on the requirement of the sdram parts used. the controller will issue refresh to two (of the eight) chip selects at a time (rather than one of four). ecc the memory controller supports an 8 bit ecc calculated over the 64 bit data. single bit errors will be detected and automatically corrected as the data passes through the controller. double bit errors are detected. in either case the data is flagged appropriately when it is sent on zbbus, correctable errors are counted by the scd; uncorrectable errors will be counted and report a data error at their destination. single bit ecc errors will be corrected during the read and the corrected data will be written back into the memory. they will continue to occupy the rqq entry until the data has been written. thus a memory location should not return multiple single bit ecc errors. double bit errors are left as such, so repeated reads of the data will continue to give the error. ecc checking can be disabled either to support non-ecc dimms or during memory testing. the memory controller can be set to write bad ecc to the memory in order to check the error handling logic and code. there are two registers mc_test_data which is 64 bits and mc_test_ecc which is 8 bits. if either of these are non-zero then during memory writes any bits that are set in these two registers will cause the corresponding data or ecc bit to be inverted during a memory write. this will force an error into the memory. if the location is subsequently read an ecc error should be reported. sdram t iming the timing for ddr sdram accesses is set per channel, so all parts on a single channel have common timing. the memory pipeline control queue and scheduler is driven from the timing information programmed for the channel and will compute its schedule to match the rules. the base timing is set by the memory clock programmed in the mc_clock_cfg register, this is divided down from the zbbus clock as outlined in section: ?clock ratios and clocking scheme? on page 107 . the mc_timing1 and mc_timing2 registers are used to configure the number of memory clock cycles required between critical events. these can be obtained from the data sheet for the sdram that is being used (or the common jedec timing specification for standard parts). most of the fields in these registers are four bits so can be set to a value between 0 and 15, however the acceptable range for the parameters is smaller than this in many cases. programming the fields outside their acceptable ranges has undefined results. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 126 section 6: dram document 1250_1125-um100-r sdram r efresh the memory controller uses the sdram auto-refresh command to refresh the memory during normal operation. the refresh interval for a channel is set (in memory clocks) in the mc_clock_cfg register. in parts where the system_revision indicates periph_rev3 or later this register also has fields to completely disable refresh (useful only during debugging, to avoid the scope being triggered by refresh cycles) or disable refresh for particular (i.e. unused) chip selects. software can cause auto refresh commands to be sent to the sdram as described in section: ?sdram initialization and commands? on page 126 . this has no effect on the refresh interval counter. sdram i nitialization and c ommands the ddr sdrams accept a number of commands that are not used as part of regular operation. these can be issued under software control by writing the mc_dramcmd register with the command to be performed and the chip selects that should be asserted when the command is executed. the memory controller will insert a synchronization point before the command is executed so that all buffers are empty. in some cases the commands require additional data encoded in the address lines. the mc_drammode register holds the data to be encoded (on address lines a[11:0] for standard ddr parts and a[14:0] for fcrams). table 69: commands that can be issued through mc_dramcmd register name command description emrs write extended mode register write the value in the mc_drammode register to the extended mode register in the selected parts. mrs write mode register write the value in the mc_drammode register to the mode register in the selected parts. pre precharge all banks issue a precharge command to the sdrams with address bit 10 high to cause all banks to be precharged. if the pre_on_8 bit is set then this command will run the precharge command with address bit 8 high. ar auto refresh issue an auto refresh command to the sdrams. sref_set enter self refresh mode set the sdram into self refresh mode by issuing a self refresh command and deasserting cke then stopping the clock. sref_clr exit self refresh mode remove the sdram from self refresh mode by starting the clock, asserting cke and issuing nop commands to the part. software must ensure that the memory is not accessed for the required time after the part is removed from self refresh mode (normally 200 memory clocks). pdn_set enter power down mode set the sdram into power down mode by issuing a nop command and deasserting cke. pdn_clr exit power down mode remove the sdram from power down mode by asserting cke and issuing nop commands to the part. software must ensure that the memory is not accessed for the required time after the part is removed from power down. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 127 when the part is reset the sdram channels are put in power-down mode with the clock stopped and cke deasserted. because cke is deasserted all devices on the memory channel will place their outputs in a high impedance state, this will prevent multiple bus drivers as the channel starts up. to initialize a channel software must first start the clock by programming the mc_clock_cfg, then wait for 200us for the clock to stabilize before giving the pdn_clr command to assert cke. next the ddr sdrams must be initialized (this also needs to be done when exiting power down mode if the dll has been disabled). the initialization sequence is specified in the sdram data sheet, however the jedec recommended sequence should be a superset of all manufacturer requirements. it is: 1 precharge all banks (pre). 2 enable the dll and set the appropriate output drive strength in the extended mode register (emrs). 3 reset the dll in the mode register (mrs). from this point no access other than the subsequent initialization steps ( 4 through 7 ) may be done for 200 memory cycles. 4 wait for 2 cycles (tmrd). 5 precharge all banks (pre). 6 issue two auto refresh cycles (ar, ar). (the jedec spec allows these to be done before the precharge in step 5 ) 7 configure the mode register for normal operation, appropriate cas latency, sequential burst and burst length of 4. (mrs) 8 once 200 memory cycles have passed since the dll was reset, the sdram is ready for normal operation. the reset initialization sequence is different for fcram from regular ddr parts. the memory controller will not release the enable (cke) when the pdn_clr command is used to start the clock, but waits for a pre command to be issued before it asserts cke and automatically runs the address sequencing initialization sequence for all chip selects. the sequence of commands needed is therefor: 1 set dram type to fcram. this must be done first. this will start the memory clock on mn_clk. 2 wait for minimum of 200us. this is required by the fcram which must have a stable clock for a minimum time before being enabled. 3 issue pdn_clr command. this asserts cke and sets the desl command with cs_l=1 ba[1:0]=00 a[8]=0 a[7]=1. this covers steps 1-6 of the standard fcram initialization sequence. 4 issue pre command. this will run the sequence starting from cs_l=1 ba[1:0]=00 a[8]=0 a[7]=1; cs_l=0 ba[1:0]=11, a[14:8]=1111111 a[7]=0 held for two clocks; cs_l=1 rest same for 4 clocks; cs_l=1 and change ba[1:0] and a[14:7], hold for 4 clocks. this covers steps 6-9 of the standard fcram initialization sequence. 5 set the mode register and issue emrs command. 6 set the mode register and issue mrs command. 7 issue two auto-refresh commands (ar, ar). 8 wait for 200 or 300 memory cycles (see fcram data sheet). 9 do a dummy write to each bank of each chip select. 10 the device is now ready for normal operation. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 128 section 6: dram document 1250_1125-um100-r i/o c ontrol the memory controller supports a wide range of sdram speeds and configurations. in particular the signal loading and propagation delays will be very different in a system that is fully populated with dimms than it is in a system with point-to-point connections between the part and sdrams soldered to the main board. the termination schemes may differ too. the timing budget and electrical characteristics must be calculated for each board the bcm1250 or BCM1125/h is used on. in most cases the correct values for the i/o control registers will be calculated during board design and verified during bring up. the electrical characteristics of the memory controller outputs can be adjusted to match the environment it is in. the drive strength (and thus slew rate for a particular loading) of the clock, address/command and data output drivers can be set in the channel configuration register ( mc_clock_cfg ). there is one bit of coarse control which changes the driver configuration between sstl_2 class 1 (7.6ma min. drive) and sstl_2 class 2 (15.2ma min. drive). in addition there are three slew bi ts that control the slew rate of the driver from fast (3?b111) to slow (3?b000). in most cases the correct setting will be the fast slew rate, but the slower rates may work better for systems with lower loading and when non-standard termination is used. important! the rest of this description explains the dlls for the bcm1250 and BCM1125/h where the system_revision indicates periph_rev2 or later. the address dll was organized differently on the early-access prototype pass-1 parts (marked bcm12500), please see an earlier revision of this user manual for description of those parts. an internal master dll is used to control slave dlls to allow adjustment of input and output timing. each dll has a fixed offset , a linear delay adjustment (6 bit unsigned number n ) and a proportional delay adjustment (4 bit unsigned number m ). the total dll delay is given by: delay = offset + ( n * dll_step )*(1+(( m -8)*5%)) this is the ideal case, in practice there is a part dependent error to the 5%, and it rolls off to more like 4% at the low end. table 70 gives the typical multiplier mult that results from the (1+(( m -8)*5%)) term. the master dll is fixed to have m =8 and derives nmaster from the memory clock period tmclk such that: delay = offset + ( nmaster * dll_step ) = tmclk /4 the offset is typically 500ps, and the resolution of dll_step is sufficient to cover memory clock frequencies from 95-200mhz. at lower frequencies the delay may saturate, however at these speeds the cycle time is so long that the proportional adjustment provided by the dll is not required. table 70: adjustment percentages and multiplier for values of dll m m m-8 adjustment% simulation result for (m-8)*5% multiplier simulation result for 1+((m-8)*5%) 4'b0000 -8 -35% 0.65 4'b0001 -7 -31% 0.69 4'b0010 -6 -27% 0.73 4'b0011 -5 -23% 0.77 4'b0100 -4 -19% 0.81 4'b0101 -3 -15% 0.85 4'b0110 -2 -10% 0.90 4'b0111 -1 -5% 0.95 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 129 the slave dlls are adjusted to have their n set to nmaster and m set to the four bit dqi_skew, dqo_skew or addr_skew field from the mc_clock_cfg register. this value m can be converted to a multiplier mult according to table 70 . the slave dll delay is given by: slavedelay = offset + ( nmaster * dll_step )* mult substituting for nmaster : slavedelay = offset + ((( tmclk /4 - offset )/ dll_step )* dll_step )* mult slavedelay = offset *(1- mult ) + ( tmclk /4)* mult the dlls are used in three places: to shift the received dqs into the center of the data valid window, to shift the relationship between the output clock and signals, and to shift the dqs driven into the center of the data window. the first is the most straightforward. during a read the dram will drive the data at the same time as it changes dqs. since the board traces between the dram and the controller are length matched (across a group of 8 data bits and one dqs for regular ddr parts, and a group of 32 data bits and dqs for sgram) the data and dqs transitions are still aligned when they are received at the memory controller. the controller delays the dqs using a dll controlled by dqi_skew. the data is valid for half of a memory cycle, so the quarter cycle base delay (with m = 4'b1000 thus mult = 1) will position the delayed dqs at the center of theoretical data window. the dll can be adjusted about 8.75% of the memory cycle (or 35% of the quarter cycle) either side of this point. the second use of the dll is to position the address and data signals relative to the memory clock. this is done by driving the data/address/control from a fixed internal clock and using the dll to move the external mn_clk with respect to the internal one. since it is the clock moving rather than the data the direction of a change can seem backwards! figure 21 shows the external view with timings relative to the clock, this is the view needed when designing the memory system. the position of the clock relative to the point at which the address and control signals change is set by the addr_skew parameter. figure 21 shows the range as t0 to t1. to get the address change earliest in the external clock cycle (shown by t0) the clock needs to be delayed by its maximum, so the addr_skew (which sets the dll m parameter from table 70 ) needs to be 4'b1111. the other extreme is shown by t1, which has the addr_skew set to 4'b0000. the range gives the delay from the rising mn_clk edge to the address transition point of approximately 16% to 34% of the memory clock cycle time. 4'b1000 0 center 1.0 4'b1001 1 5% 1.05 4'b1010 2 10% 1.10 4'b1011 3 15% 1.15 4'b1100 4 20% 1.20 4'b1101 5 25% 1.25 4'b1110 6 30% 1.30 4'b1111 7 35% 1.35 table 70: adjustment percentages and multiplier for values of dll m (cont.) m m-8 adjustment% simulation result for (m-8)*5% multiplier simulation result for 1+((m-8)*5%) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 130 section 6: dram document 1250_1125-um100-r the drive position of the data relative to clock (t4 and t5) is controlled by the addr_skew parameter in the same way as the address, except the data changes on both edges of the clock. the data transition point is thus offset from both edges of the mn_clk by about 16% to 34% of the memory clock cycle time. the third use of a dll is to position the dqs strobe relative to the data during a write to the memory. the dqs transition needs to be shifted to the center of the data valid window. this is done by shifting the dqs transition from the data transition using a dll controlled by the dqo_skew. the minimum delay between the data and dqs (t6 in figure 21 ) is about 16% of the cycle time when dqo_skew is 4'b0000, the maximum (shown as t7) is about 34% of the cycle time with dqo_skew set to 4'b1111. the second and third uses of the dll interact to set the position of the dqs output relative to the clock. the difference between the addr_skew and dqo_skew controls this delay (if they are set to the same value the strobe will line up with the clock). the early dqs shown by t2 results from the addr_skew being set to m =4'b1111 and dqo_skew to m =4'b0000, the difference in the delays will make the dqs precede the clock by (35 - (-35)) = 70% of a quarter cycle or 17.5% of the cycle time. the late dqs shown by t3 is the reverse situation and will have the dqs 17.5% of the cycle time after the clock. figure 21: timing relationships set by dlls mn_clk adrctlearly adrctllate dataearly datalate dqsoutearly dqsoutlate t0 t1 t2 t3 t4 t5 t6 t7 address delay from clock is 16% -34% of cycle set by addr_skew dqs out delay from clock is -17.5% to +17.5% of cycle, set by difference between addr_skew and dqo_skew data delay from clock is 16%-34% of cycle set by addr_skew dqs delay from data is 16%-34% of cycle set by dqo_skew user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 131 t iming p arameter g uidelines the memory controller timing parameters must be configured to match the devices and board delays in the system. this section gives some guidelines for the parameters. during a read from memory the controller will use the dqs strobe supplied with each byte of the data to latch the four data-beats. the data is subsequently read out and passed to the dbf data buffer. since there will be skew across the nine dqs lines, the different bytes are captured from the memory at different times, but they are eventually read out of the latch as a single value. there are three factors that influence the timing. (1) the controller must not start looking for dqs until the sdram drives it to a valid low as part of the preamble. (2) the controller must start looking for the dqs before the earliest dqs returns. (3) the data must not be read from the latch before the byte with the latest dqs has been written and allowed to settle. taken together these constraints fix the window in which the first dqs of each byte lane must be received at the controller. the tcrd, tcrdh and tfifo parameters in the mc_timing1 register describe this window. as a starting point the tcrd is the integer part of the cas latency, the tcrdh is set for half-cycle cas latency and the tfifo is set to 1 for normal delay in reading out from the data latch. the full story is shown in figure 22 which shows the window for the first dqs relative to clock for different settings of the three parameters. the count n represents the number of cycles since cas, so for a cas latency n device the ideal dqs would be at the rising edge that starts cycle n. figure 22: nominal windows at 133mhz for first edge of dqs for various settings of [tcrd, tcrdh, tfifo] ticks after cas n-1 n n+1 n+2 mclk [n,0,1] [n,1,1] [n,0,2] [n,1,2] [n+1,0,1] [n+1,1,1] [n+1,0,2] [n+1,1,2] [n-1,0,2] [n-1,1,2] bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 132 section 6: dram document 1250_1125-um100-r this figure shows where in time the first dqs edges must occur for various settings of the parameters [tcrd, tcrdh, tfifo]. the following table describes the opening and closing of the windows for different parameter settings: note that both the mclk and the dqs are observed at the pins of the controller. when a memory system is analyzed the loop delay must be considered: the clock is driven from the controller and takes time to propagate to the sdram, the sdram will drive dqs in some window around when it receives the clock edge and dqs will take time to propagate back. in a heavily loaded channel (or with lower drive strength) there may also be a contribution to the delay from the rise/fall time of the clock and dqs. the dqs signals are all being driven by different sdram chips and may have different propagation delays (since the board trace length difference between the 8 data bits and their dqs is more tightly controlled than the difference across the dqs bundles). in systems with dimms there may be a non-negligible difference in response between a device on the first dimm and a device on the last dimm of the channel, increasing the uncertainty in dqs arrival time. the positions of the windows are affected by the settings of the dlls described in the previous section. they are shown for the center dll position ( m =4?b1000). increasing the value of addr_skew will move the windows to the left (this is not true on the initial pass1 prototypes with the earlier address dll arrangement, in those parts increasing dqo_skew will move the window to the left). increasing the value of dqi_skew will move the windows to the left (this is true on all parts). the positions of the windows are also affected by the settings of the clock_class and clock_drive parameters in the memory clock configuration register. the windows in the figure are shown for clock_class=1 and clock_drive=7 (i.e. maximum drive strength sstl_2 class ii). values other than these will move the windows to the left. if the memory system is running slower than 95mhz, it is possible that the dlls in the memory controller will saturate (i.e., reach their maximum possible delay). when this happens, the windows will move to the right. a few of the settings are not useful in practice. there is no reason to use the setting [n,1,1] since it is a subset of the [n,0,1], [n, 0, 2] and [n, 1, 2] settings and has a narrower window that all nine dqs signals must hit. the setting for [n-1,0,2] is also not particularly useful. it is only shown for completeness. the setting for [n-1,1,2] is probably only useful to systems running with such a slow memory clock that the dll's have saturated. this setting is misleading the controller about the actual cas latency of the sdram. the controller will therefore expect the sdram to release the bus earlier, which must be compensated for by always setting r2widle to 1 to restore the cycle in a read to write turnaround. table 71: first dqs window opening and closing (typical) setting window opening window closing [n, 0, 1] 1.5ns before rising edge 3.5ns before rising edge of cycle n+1 [n, 1, 1] 1.5ns before falling edge 3.5ns before rising edge of cycle n+1 [n, 0, 2] 1.5ns before rising edge 2.0ns before falling edge of cycle n+1 [n, 1, 2] 1.5ns before falling edge 2.5ns before falling edge of cycle n+1 plus ? cycle user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 133 as an example, consider a memory system with parts soldered to the mainboard using cas latency 2.5 parts. the simple view would suggest [2, 1, 1] as the starting point. however referring to the figure, we note that with this setting at 133mhz, the window has closed before the earliest point where we might expect dqs to return. as a general rule, systems using cas latency 2.5 should use either [2,0,2] or [2,1,2]. which of these settings is better depends on the memory system round trip delay, the dll settings, and the setting for memory clock drive strength. continuing the example, suppose we run the memory at cas latency 2. in this case the expected setting, [2,0,1], is generally the correct setting. but now suppose that for some reason the memory clock needs to be run slow (below 95mhz). all of the windows in the figure will move right. and in the lightly loaded system the dqs arrival will be relatively early. the width of the [2,0,1] window will continue to work for some time because it can move for a reasonable distance until the opening point reaches the early dqs (which the ddr spec would allow to be before the clock edge). at some frequency the first dqs will not be correctly used to strobe the data and the data received later in the burst will overwrite the earlier (the memory controller reads into the low numbered bits of the zbbus first, so when this happens the data in the low memory address end of a cache line will be unpredictable and the data at the high address will have the value expected from the low address). this is where the memory controller needs to be programmed with a smaller cas latency (and r2widle set to 1) to use the right shifted [1,1,2] window. most systems will likely want to use one of the following settings: [n,0,1] for whole cycle cas latencies and relatively short board delays. [n,0,2] for whole cycle cas latencies with moderately long board delays. [n,1,2] for half-cycle cas latencies. (due to a performance bug systems with half-cycle cas latencies using bcm1250 pass 1 prototype parts should use [n,0,2] if possible). there are three additional parameters r2widle, w2ridle, and r2ridle that address system timing concerns, specifically bus conflicts caused by the time delay between signals driven by the controller and signals driven by the sdrams. the r2widle parameter sets the turnaround time from the memory driving the databus (on a read) to the controller driving the databus (for a subsequent write). it is independent of whether the accesses are to the same physical bank or different physical banks. assuming a whole cycle cas latency for the sdram, a setting of 0 for the r2widle parameter nominally provides 0.75 cycles of non-overlap time for the dq lines. but at the controller, this non-overlap time is reduced by the clock delay from the controller to the sdram and the dq delay from the sdram to the controller. further, if the sdram cas latency is set to some half-cycle value, the non-overlap time is reduced by another 0.5 cycle. so systems using sdrams with a half-cycle cas latency value almost certainly need to set the r2widle parameter to a 1, increasing the non-overlap time by one cycle. systems using whole-cycle cas latency values may need to set this parameter to a 1 if the round-trip delays between the controller and the sdrams are significant compared to the clock period. the w2ridle parameter sets the turnaround time for the controller driving the databus to the memory driving the databus when physical banks are changed. it should always be set to 1. the r2ridle parameter sets the turnaround time between a read from one physical bank to a read from a different physical bank. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 134 section 6: dram document 1250_1125-um100-r a value of 0 for the r2ridle parameter nominally provides 1 cycle of non-overlap for the dq lines at the physical bank of sdrams being read first. at the physical bank that is the target of the second read, this nominal value is reduced by the dq delay between the two physical banks. the dqs non-overlap time is nominally 0, but since both physical banks are driving the dqs lines low during the turnaround, there is nominally 0.5 cycle of margin before a conflict occurs on the dqs lines at the first physical bank. once again, at the second physical bank of sdrams, this 0.5 cycle of nominal no conflict time is reduced by the dqs delay between the two physical banks. therefore it is unlikely that a system will require a non-zero value of the r2ridle parameter. to summarize, most systems using half-cycle cas latency will set r2widle to a 1, w2ridle to a 1, and r2ridle to a 0. systems using sdrams with a whole-cycle cas latency will set r2ridle to 1 and the other parameters to 0. systems configuring an n-1 value for tcrd will need to set r2widle to 1. p erformance m onitoring f eatures the memory controller provides signals to the performance counters in the scd (see section: ?system performance counters? on page 61 ). add discussion. zb bus m onitoring the functionality described in this section in previous releases of the bcm1250 manual was for the prototype chips only and is no longer available. the trace buffer in the scd (see ?trace unit? on page 70 ) should be used to monitor the zbbus. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 135 c onfiguration r egisters all memory controller configuration registers are 64 bit wide and they must be written using double-word accesses. if writes smaller than 64 bits are done to a control register its contents become unpredictable. on the BCM1125/h, all registers of memory channel 0, except mc_config_0 are not implemented . table 72: memory channel configuration register on bcm1250 mc_config_0 - 00_1005_1100 mc_config_1 - 00_1005_2100 bits name default description 7:0 reserved 8?b0 reserved 15:8 channel_sel 8?h0 if this field is zero the two channels are not interleaved. if this field is non zero it specifies the address bit that selects between the two channels, and must have a value in the range 5-35. if the channels are interleaved the other configuration parameters must match. 19:16 bank0_map 4?h0 value of physical address bits [31:28] that should map to 0 (1st 256mb block) 23:20 bank1_map 4?h8 value of physical address bits [31:28] that should map to 1 (2nd 256mb block) 27:24 bank2_map 4?h9 value of physical address bits [31:28] that should map to 2 (3rd 256mb block) 31:28 bank3_map 4?hc value of physical address bits [31:28] that should map to 3 (4th 256mb block) 39:32 probe_mode 8?b0 reserved, broadcom use only. setting these bits to any value other than zero will result in undefined behavior and can cause the ecc lines to be continually driven regardless of the direction of the data transfer. 43:40 iob1_qsize 4?ha these fields are used to set the range of queue entries reserved for use by i/o bridge 1. the two channel configuration registers set a range to give hysteresis to the blocking. mc_config_0 : queue size to start blocking agents other than iob1. mc_config_1 : queue size to stop blocking agents other than iob1. 47:44 age_limit 4?h8 maximum number of younger reads that can pass a read in the request queue, before the read is serviced. see section: ?memory controller architecture? on page 104 . 51:48 wr_limit 4?h5 maximum number of writes in a burst to memory before reads will be serviced. see section: ?memory controller architecture? on page 104 . 52 iob1_priority 1?b1 mc_config_1 : if this bit is set reads from i/o bridge 1 will be given high priority (to reduce their latency). if clear all requests have the same priority. mc_config_0 : reserved. 55:53 reserved 3?b0 reserved 59:56 cs_mode 4?h0 chip selection mode 0000: msb-cs mode: cs[3:0]are determined by the corresponding cs start/end+1 address registers. 1111: interleaved-cs mode: the values of start/end+1 addresses of cs[3:0] are all same in this mode, cs[3:0] are decoded by the two bits in the interleaved cs position register. 1100: mixed-cs mode: cs[1] and cs[0] are not interleaved and determined by the corresponding start/end+1 addresses.the interleaving occurs between cs3 and cs2, determined by one bit of the interleaved cs position register. the values of the cs[3:2] start/end+1 addresses are the same. 0110: mixed-cs mode: cs[3] and cs[0] are not interleaved and determined by the corresponding start/end+1 addresses. the interleaving occurs between cs2 and cs1, determined by one bit of the interleaved cs position register. the values of the cs[2:1] start/end+1 addresses are the same. 0011: mixed-cs mode: cs[3] and cs[2] are not interleaved and determined by the corresponding start/end+1 addresses. the interleaving occurs between cs1 and cs0, determined by one bit of the interleaved cs position register. the values of the cs[1:0] start/end+1 addresses are the same. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 136 section 6: dram document 1250_1125-um100-r 60 ecc_disable 1?b0 ecc disable. if this bit is set ecc checking will not be performed and data will never be reported to have an error. 61 berr_disable 1?b0 bus error disable. this bit sets the behavior when a read is done to an address that does not match any chip select range. 0: generate a bus error data return 1: generate a valid data return containing unpredictable data. on the bcm1250 if this bit is set in either channel, bus errors will be disabled for all reads. 62 force_seq 1?b0 force sequential. if this bit is set requests will be issued to memory in the same order their a-phase happens on the zbbus. 63 debug 1?b0 this bit enables debug functions in the controller. it should be clear during normal operation. the action if the bit is set is different for the two channels: channel 0: reserved channel 1: broadcom use only ( was enable zbbus monitoring mode). table 73: memory channel configuration register on BCM1125/h mc_config_0 - 00_1005_1100 mc_config_1 - 00_1005_2100 bits name default description 15:0 reserved 16?b0 reserved 19:16 bank0_map 4?h0 mc_config_1 : value of physical address bits [31:28] that should map to 0 (1st 256mb block) mc_config_0 : reserved. 23:20 bank1_map 4?h8 mc_config_1 : value of physical address bits [31:28] that should map to 1 (2nd 256mb block) mc_config_0 : reserved. 27:24 bank2_map 4?h9 mc_config_1 : value of physical address bits [31:28] that should map to 2 (3rd 256mb block) mc_config_0 : reserved. 31:28 bank3_map 4?hc mc_config_1 : value of physical address bits [31:28] that should map to 3 (4th 256mb block) mc_config_0 : reserved. 39:32 probe_mode 8?b0 mc_config_1 : reserved, broadcom use only. setting these bits to any value other than zero will result in undefined behavior and can cause the ecc lines to be continually driven regardless of the direction of the data transfer. mc_config_0 : reserved. 43:40 iob1_qsize 4?ha these fields are used to set the range of queue entries reserved for use by i/o bridge 1. the two channel configuration registers set a range to give hysteresis to the blocking. mc_config_0 : queue size to start blocking agents other than iob1. mc_config_1 : queue size to stop blocking agents other than iob1. 47:44 age_limit 4?h8 mc_config_1 : maximum number of younger reads that can pass a read in the request queue, before the read is serviced. see section: ?memory controller architecture? on page 104 . mc_config_0 : reserved. 51:48 wr_limit 4?h5 mc_config_1 : maximum number of writes in a burst to memory before reads will be serviced. see section: ?memory controller architecture? on page 104 . mc_config_0 : reserved. table 72: memory channel configuration register on bcm1250 (cont.) mc_config_0 - 00_1005_1100 mc_config_1 - 00_1005_2100 bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 137 52 iob1_priority 1?b1 mc_config_1 : if this bit is set reads from i/o bridge 1 will be given high priority (to reduce their latency). if clear all requests have the same priority. mc_config_0 : reserved. 55:53 reserved 3?b0 reserved 59:56 cs_mode 4?h0 mc_config_1 : chip selection mode 0000: msb-cs mode: cs[3:0]are determined by the corresponding cs start/end+1 address registers. 1111: interleaved-cs mode: the values of start/end+1 addresses of cs[3:0] are all same in this mode, cs[3:0] are decoded by the two bits in the interleaved cs position register. 1100: mixed-cs mode: cs[1] and cs[0] are not interleaved and determined by the corresponding start/end+1 addresses. the interleaving occurs between cs3 and cs2, determined by one bit of the interleaved cs position register. the values of the cs[3:2] start/end+1 addresses are the same. 0110: mixed-cs mode: cs[3] and cs[0] are not interleaved and determined by the corresponding start/end+1 addresses.tthe interleaving occurs between cs2 and cs1, determined by one bit of the interleaved cs position register. the values of the cs[2:1] start/end+1 addresses are the same. 0011: mixed-cs mode: cs[3] and cs[2] are not interleaved and determined by the corresponding start/end+1 addresses. the interleaving occurs between cs1 and cs0, determined by one bit of the interleaved cs position register. the values of the cs[1:0] start/end+1 addresses are the same. mc_config_0 : reserved. 60 ecc_disable 1?b0 mc_config_1 : ecc disable. if this bit is set ecc checking will not be performed and data will never be reported to have an error. mc_config_0 : reserved. 61 berr_disable 1?b0 mc_config_1 : bus error disable. this bit sets the behavior when a read is done to an address that does not match any chip select range. 0: generate a bus error data return 1: generate a valid data return containing unpredictable data. mc_config_0 : reserved. 62 force_seq 1?b0 mc_config_1 : force sequential. if this bit is set requests will be issued to memory in the same order their a-phase happens on the zbbus. mc_config_0 : reserved. 63 reserved 1?b0 reserved table 73: memory channel configuration register on BCM1125/h (cont.) mc_config_0 - 00_1005_1100 mc_config_1 - 00_1005_2100 bits name default description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 138 section 6: dram document 1250_1125-um100-r table 74: memory clock configuration register mc_clock_cfg_0 - 00_1005_1500 mc_clock_cfg_1 - 00_1005_2500 bits name default description 3:0 clk_ratio 4?h4 zbclk/mclk ratio mclk when zbclk=400 mhz 0100 2x 200 0101 2.5x 160 0110 3x 133 0111 3.5x 114 1000 4x 100 1001 4.5x 88 others reserved 7:4 cs_absence 4?h0 on parts with system_revision periph_rev3 setting these bits will disable the refresh cycle for the corresponding chip select. on earlier revisions all chip selects will always be refreshed. 15:8 ref_rate 8?hc4 refresh rate: (value+1) x 16 mclk examples are: 8'h62 99(x16) mclk cycles at 100mhz (15.84us). 8'h81 130(x16) mclk cycles at 133mhz (15.64us). 8'hc4 197(x16) mclk cycles at 200mhz (15.76us). note that the controller will refresh one chip select at a time (to save the power spike of all the sdrams refreshing simultaneously) so refresh cycles will be seen on the channel four times as often as this field implies (in large memory mode two chip selects are refreshed at a time). 18:16 clock_drive 3?b111 this sets the drive strength (and therefore slew rate) of the output drivers for the clocks. 0 gives the weakest drive (slowest slew rate) and 7 the hardest. see section: ?i/o control? on page 128 . 19 clock_class 1?b1 this bit should be clear to have the clock drivers configured for sstl_2 class 1 operation, and set for sstl_2 class 2. 22:20 data_drive 3?b0 this sets the drive strength (and therefore slew rate) of the output drivers for the data lines. 0 gives the weakest drive (slowest slew rate) and 7 the hardest. see section: ?i/ o control? on page 128 . 23 data_class 1?b0 this bit should be clear to have the data drivers configured for sstl_2 class 1 operation, and set for sstl_2 class 2. 26:24 addr_drive 3?b0 this sets the drive strength (and therefore slew rate) of the output drivers for the address and control lines. 0 gives the weakest drive (slowest slew rate) and 7 the hardest. see section: ?i/o control? on page 128 . 27 addr_class 1?b0 this bit should be clear to have the address and control drivers configured for sstl_2 class 1 operation, and set for sstl_2 class 2. 29:28 reserved 2?b0 reserved 30 ref_disable 1?b0 on bcm1250 prior to periph_rev3: reserved on other parts: if this bit is set refresh cycles are disabled. this can be useful during debugging, but must not be set in normal operation. 31 dll_bypass 1?b0 set this bit to bypass the dlls. this should not be set in normal operation. 35:32 dqi_skew 4?b1000 dqs to data input skew control. see section: ?i/o control? on page 128 . 39:36 reserved 4?b0 reserved 43:40 dqo_skew 4?b1000 dqs to data output skew control. see section: ?i/o control? on page 128 . 47:44 reserved 4?b0 reserved 51:48 addr_skew 4?b1000 address/control output delay from rising memory clock. see section: ?i/o control? on page 128 . 55:52 reserved 4?b0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 139 61:56 dll_default 6?b010000 this is the value to use in place of the dll output when dll bypass is enabled. 63:62 reserved 2?b0 reserved table 74: memory clock configuration register (cont.) mc_clock_cfg_0 - 00_1005_1500 mc_clock_cfg_1 - 00_1005_2500 bits name default description table 75: dram command register mc_dramcmd_0 - 00_1005_1120 mc_dramcmd_1 - 00_1005_2120 write only bits name description 3:0 command command to issue to the sdram 0000: emrs write the extended mode register (emr) (ba[1:0] = 01) 0001: mrs write the mode register (mr) (ba[1:0] = 00) 0010: precharge all banks 0011: auto refresh (ar) 0100: set self-refresh 0101: clear self-refresh 0110: set power-down 0111: clear power-down 4 cs0 if this bit is set, cs0 is asserted when the command is issued. 5 cs1 if this bit is set, cs1 is asserted when the command is issued. 6 cs2 if this bit is set, cs2 is asserted when the command is issued. 7 cs3 if this bit is set, cs3 is asserted when the command is issued. 63:8 reserved reserved table 76: dram mode register mc_drammode_0 - 00_1005_1140 mc_drammode_1 - 00_1005_2140 bits name default description 12:0 emode 15?b0 this value is written to the extended mode register via the address lines when the emrs command is issued to the mc_dramcmd register. 14:13 these bits provide the additional two bits to send on address bits 14:13 during an emrs command to fcrams. they are ignored for standard ddr sdrams. 15 reserved 1?b0 reserved 28:16 mode 15?h22 this value is written to the mode register via the address lines when the mrs command is issued to the mc_dramcmd register. the mode register must always be programmed for sequential burst order and a burst length of 4. if not memory accesses will be unpredictable. 30:29 these bits provide the additional two bits to send on address bits 14:13 during an mrs command to fcrams. they are ignored for standard ddr sdrams. 31 reserved 1?b0 reserved bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 140 section 6: dram document 1250_1125-um100-r 34:32 dram_type 3?b0 dram type: 000: jedec ddr (one dqs for every 8 dq bits) 001: fcram 010: ddr sgram (one dqs for every 32 dq bits) others reserved 35 large_mem 1?b0 if this bit is set large memory support (using an external chip select decoder) is enabled. see section: ?larger memory systems? on page 124 . 36 pre_on_a8 1?b0 if this bit is set the autoprecharge flag will be output on the a8 address bit rather than a10. (only supported on parts with system revision periph_rev3 or greater). 37 ram_with_a13 1?b0 this bit should be set when the large_mem bit is set if the row address uses a13. it causes the cs[3:2] to be driven from bits [15:14] of the row address mask. it also needs to be set to cause ba[2] to be output on a13 rather than a12 for non-standard 8 bank drams. (only supported on parts with system revision periph_rev3 or greater). 63:38 reserved 26?b0 reserved table 76: dram mode register (cont.) mc_drammode_0 - 00_1005_1140 mc_drammode_1 - 00_1005_2140 bits name default description table 77: sdram timing register mc_timing1_0 - 00_1005_1160 mc_timing1_1 - 00_1005_2160 bits name range default description 3:0 trcd 1-6 4?h3 ras to cas delay. this should be set to 1 for fcrams. 6:4 tcrd 1-6 3?h2 cycles from cas(read) to data (the cas latency). 7 tcrdh 0-1 1?b0 if this bit is set the data capture is delayed by a half cycle from the integer part of the cas latency set in tcrd. see the discussion in ?timing parameter guidelines? on page 131 . 11:8 tcwd 1-2 or 1-4 4?h1 delay from cas to write data. on parts with system revision periph_rev3 or greater the range is extended to 1-4. 15:12 reserved 0 4?h0 reserved 19:16 trp 1-4 4?h4 cycles required from precharge to ras. 23:20 trrd 1-4 4?h2 cycles required from ras to ras for a different bank. 27:24 trcw-1 1-15 4?ha one less than cycles required from ras(write) to next ras of the same bank. 31:28 trcr-1 1-15 4?h9 one less than cycles required from ras(read) to next ras of the same bank. 35:32 reserved 0 4?h0 reserved 39:36 reserved 0 4?h0 reserved 43:40 tcwcr 0-15 4?h4 cycles of separation from write to read. this field is calculated as: tcwcr = trcw - (trcd + tcwd + 2 + twtr) note that trcw is one greater than the value set in trcw-1 field and twtr is the internal write to read delay for the sdram (normally specified as 1 cycle). 47:44 reserved 0 4?h0 reserved 51:48 reserved 0 4?h0 reserved 55:52 trfc 0-15 4?hc cycles required from auto-refresh to active or auto-refresh. 59:56 tfifo 0-1 4?h1 additional cycles required for data capture fifo. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 141 60 w2ridle 0-1 1?b1 number of idle cycles required for write to read turnaround. this bit must always be set. 61 r2widle 0-1 1?b1 number of idle cycles required for read to write turnaround. if this bit is 0 one idle cycle is used. if this bit is 1 two idle cycles are used. usually set for half cycle cas latencies and cleared otherwise. 62 r2ridle 0-1 1?b1 number of idle cycles required for read to read of a different chip turnaround. if this bit is 0 one idle cycle is used. if this bit is 1 two idle cycles are used. this bit is usually 0. 63 reserved 0 1?b0 reserved table 77: sdram timing register (cont.) mc_timing1_0 - 00_1005_1160 mc_timing1_1 - 00_1005_2160 bits name range default description table 78: sdram timing register 2 mc_timing2_0 - 00_1005_1180 mc_timing2_1 - 00_1005_2180 bits name description 63:0 reserved reserved table 79: chip select start address register mc_cs_start_0 - 00_1005_11a0 mc_cs_start_1 - 00_1005_21a0 bits name default ch0 default ch1 default ch1 (BCM1125/h) description 15:0 cs0_start 16?h0000 16?h0100 16?h0000 chip select 0,1,2,3 region start address bits [39:24]. these address are in the memory address space (after the translation described in section: ?mapping? on page 109 ). 31:16 cs1_start 16?h0010 16?h0000 16?h0010 47:32 cs2_start 16?h0020 16?h0000 16?h0020 63:48 cs3_start 16?h0030 16?h0000 16?h0030 table 80: chip select end address register mc_cs_end_0 - 00_1005_11c0 mc_cs_end_1 - 00_1005_21c0 bits name default ch0 default ch1 default ch1 (BCM1125/h) description 15:0 cs0_end 16?h0010 16?h0200 16?h0010 chip select 0,1,2,3 region end address + 1 bits [39:24]. these address are in the memory address space (after the translation described in section: ?mapping? on page 109 ). 31:16 cs1_end 16?h0020 16?h0000 16?h0020 47:32 cs2_end 16?h0030 16?h0000 16?h0030 63:48 cs3_end 16?h0040 16?h0000 16?h0040 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 142 section 6: dram document 1250_1125-um100-r table 81: chip select interleave register mc_cs_interleave_0 - 00_1005_11e0 mc_cs_interleave_1 - 00_1005_21e0 bits name default description 4:0 reserved 5?b0 reserved 24:5 interleave 20?b0 for mixed_cs mode single set bit should be written to this register in the bit position that should be used to select between the two chip selects in the interleaved portion. for interleaved_cs mode two adjacent bits should be set in this register in the bit positions that should be used to select between the four chip selects. 63:25 reserved 39?b0 must be zero. table 82: row address bits select register mc_cs0_row_0 - 00_1005_1200 mc_cs1_row_0 - 00_1005_1260 mc_cs2_row_0 - 00_1005_12c0 mc_cs3_row_0 - 00_1005_1320 mc_cs0_row_1 - 00_1005_2200 mc_cs1_row_1 - 00_1005_2260 mc_cs2_row_1 - 00_1005_22c0 mc_cs3_row_1 - 00_1005_2320 bits name description default: (4k) 64?b00000000_00000000_00000000_00000000_00000111_11111111_10000000_00000000 9:0 reserved reserved 34:10 select address bits are selected for use as the row address by setting the corresponding bits in this register. the number of bits set should match the number of rows of the sdram. the set bits must be contiguous. 63:35 reserved must be zero. table 83: column address bits select register mc_cs0_col_0 - 00_1005_1220 mc_cs1_col_0 - 00_1005_1280 mc_cs2_col_0 - 00_1005_12e0 mc_cs3_col_0 - 00_1005_1340 mc_cs0_col_1 - 00_1005_2220 mc_cs1_col_1 - 00_1005_2280 mc_cs2_col_1 - 00_1005_22e0 mc_cs3_col_1 - 00_1005_2340 bits name description default: (1k) 64?b00000000_00000000_00000000_00000000_00000000_00000000_01111111_10000000 4:0 reserved reserved (the controller always acts as if bits 4:3 are set.) 20:5 select address bits are selected for use as the column address by setting the corresponding bits in this register. the number of bits set should match the number of columns of the sdram. the set bits must be countiguous, with two exceptions bit 5 set and the other bits contiguous (this allows for bank, cs or channel interleave on 64 byte blocks) bit 5 and 6 set and the other bits contiguous (this allows for bank, cs or channel interleave on 128 byte blocks) user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 143 63:21 reserved must be zero. table 83: column address bits select register (cont.) mc_cs0_col_0 - 00_1005_1220 mc_cs1_col_0 - 00_1005_1280 mc_cs2_col_0 - 00_1005_12e0 mc_cs3_col_0 - 00_1005_1340 mc_cs0_col_1 - 00_1005_2220 mc_cs1_col_1 - 00_1005_2280 mc_cs2_col_1 - 00_1005_22e0 mc_cs3_col_1 - 00_1005_2340 bits name description table 84: bank address bits select register mc_cs0_ba_0 - 00_1005_1240 mc_cs1_ba_0 - 00_1005_12a0 mc_cs2_ba_0 - 00_1005_1300 mc_cs3_ba_0 - 00_1005_1360 mc_cs0_ba_1 - 00_1005_2240 mc_cs1_ba_1 - 00_1005_22a0 mc_cs2_ba_1 - 00_1005_2300 mc_cs3_ba_1 - 00_1005_2360 bits name description default: 64?b00000000_00000000_00000000_00000000_00000000_00000000_00000000_01100000 4:0 reserved reserved 36:5 select address bits are selected for use as the bank address by setting the corresponding bits in this register. the number of bits set should match the number of banks of the sdram. the set bits must be countiguous. 63:37 reserved must be zero. table 85: chip select attribute register mc_cs_attr_0 - 00_1005_1380 mc_cs_attr_1 - 00_1005_2380 bits name default description 1:0 cs0_page 2?b01 page policy for chip select 0. (see section: ?page policy? on page 122 .) 00: closed page. autoprecharge every cas. 01: cas time check, autoprecharge unless there is another request in the queue. 10: hint based check, as cas time check but including hint signal. 11: open page. the page is always left open. 15:2 reserved 14?h0 must be zero. 17:16 cs1_page 2?b01 page policy for chip select 1. (see section: ?page policy? on page 122 .) 00: closed page. autoprecharge every cas. 01: cas time check, autoprecharge unless there is another request in the queue. 10: hint based check, as cas time check but including hint signal. 11: open page. the page is always left open. 31:18 reserved 14?h0 must be zero. 33:32 cs2_page 2?b01 page policy for chip select 2. (see section: ?page policy? on page 122 .) 00: closed page. autoprecharge every cas. 01: cas time check, autoprecharge unless there is another request in the queue. 10: hint based check, as cas time check but including hint signal. 11: open page. the page is always left open. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 144 section 6: dram document 1250_1125-um100-r 47:34 reserved 14?h0 must be zero. 49:48 cs3_page 2?b01 page policy for chip select 3. (see section: ?page policy? on page 122 .) 00: closed page. autoprecharge every cas. 01: cas time check, autoprecharge unless there is another request in the queue. 10: hint based check, as cas time check but including hint signal. 11: open page. the page is always left open. 63:50 reserved 14?h0 must be zero. table 85: chip select attribute register (cont.) mc_cs_attr_0 - 00_1005_1380 mc_cs_attr_1 - 00_1005_2380 bits name default description table 86: ecc test data register mc_test_data_0 - 00_1005_1400 mc_test_data_1 - 00_1005_2400 bits name default description 63:0 invert 64?h0 this value is xored with the data written to memory. any bits set in this register will cause the corresponding data bit to be inverted compared to the data the ecc bits were calculated for. if only one bit is set a correctable ecc error should result from a read. if two bits are set an uncorrectable ecc error should result from a read. table 87: ecc test ecc register mc_test_ecc_0 - 00_1005_1420 mc_test_ecc_1 - 00_1005_2420 bits name default description 7:0 invert 8?h0 this value is xored with the ecc code written to memory. any bits set in this register will cause the corresponding ecc bit to be inverted compared to value that was calculated from the data. if only one bit is set a correctable ecc error should result from a read. if two bits are set an uncorrectable ecc error should result from a read. 63:8 reserved 56?h0 must be zero. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 6: dram page 145 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 146 section 6: dram document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 147 section 7: dma dma c ontrollers there are several dma controllers. the programming interface is similar for all of them and is described in this section. each synchronous serial port has a transmit and a receive dma channel and each ethernet interface has two transmit and two receive dma channels. a dma channel has a group of descriptors which may either be organized as a ring (in which case each descriptor can point to two memory buffers) or a chain (in this case there is only one memory buffer associated with a descriptor and the other pointer is the link pointer to the next descriptor in the chain). each descriptor contains some control bits that are used to select interface options, and following packet transfer the dma controller will update some flag bits. the configuration registers for the ethernet and serial interfaces are the same. the descriptions in this section use generic names. the actual register names for the ethernet interfaces are generated by appending _mac_ n _rx_ch_ m for receive channel m (0,1) of ethernet interface n (0,1 for the BCM1125/h and 0,1,2 for the bcm1250), and _mac_ n _tx_ch_ m for the transmit channels. the register names for the serial interfaces are generated by appending _ser_ n _rx and _ser_ n _tx for serial interface n (0,1). there is an additional generic data mover for doing tr ansfers between arbitrary addresses (both memory and i/o can be addressed). this is similar in style to the other dma controllers, but has a slightly different programming interface since it needs to support both source and destination addresses. the general discussion in the following sections applies to the data mover, specific details are given in section: ?data mover? on page 176 . d ata b uffers and d escriptors there are two fundamental elements in the dma system: data buffers and descriptors. data buffers are sized areas of the physical address space that hold data. descriptors point to data buffers and hold their parameters. receive dma controllers move bytes between an interface and a data buffer, transmit dma controllers move bytes between a data buffer and an interface, and data mover dma controllers move bytes between two data buffers. in many systems a data buffer resides in the main memory. however, there is no need for this to be the case, the address generated by the dma controller is interpreted in the same way that a cpu physical address would be, thus the controller in the ethernet interface could transfer packets directly to a device on the hypertransport fabric without the data going through memory (for example if incoming packets are encrypted and must be passed through a decryption engine before the cpu can use them). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 148 section 7: dma document 1250_1125-um100-r figure 23: dma buffer figure 23 shows a data buffer as used by the ethernet and serial interfaces (data mover buffers are the same but the alignment restrictions are removed). three parameters describe a data buffer: there are an additional two parameters that describe the data in buffers: packet start address offset in bytes size (in cache blocks) length in bytes aligned to 32 byte block aligned to 32 byte block table 88: data buffer parameters start address the start address of a data buffer is the 40 bit physical address at which the buffer starts. in the ethernet and serial port dma engines it must be cache block aligned, so the lowest five bits of the address must be zero. the data mover buffers can have arbitrary alignment. the ethernet mac dma engines in parts where system_revision indicates periph_rev3, or later, have an additional mode that allows arbitrary alignment. size the size of the data buffer is given in cache blocks, i.e. the buffer must be a multiple of 32 bytes in size. prior to periph_rev3, if a transmit channel is configured in two block fetch mode (by setting the tbx_en bit in the dma_config0 register) the buffer size must be a multiple of 64 bytes the maximum size buffer is 512 blocks (16 kbytes). the data mover does not use the size field, the buffer length matches the length parameter described below. owner the data buffer is either owned by one of the dma controllers or by the system software. ownership is not explicit, each dma controller has a count of the number of descriptors it owns and will use all buffers pointed to from those descriptors. software needs to keep track of the buffers and must update the count when passing ownership. (when software writes to the counter the value written will be added to the existing count, the software does not need to do a read-modify-write operation). table 89: data parameters length this is the length in bytes of the valid packet data in the buffer. the length may be greater than the current buffer size, in which case the packet spans multiple buffers. if the packet spans multiple descriptors then the length field in the first descriptor is used, and the length given in the subsequent descriptors is ignored. the maximum packet size for interface dma engines is 16 kb-1, the maximum size for the data mover is 1 mb. offset this is the offset in bytes of the start of the data. the offset can be between 0 and 31 bytes. if a packet spans multiple buffers, the offset is only applied to the first buffer. the offset can be used to align the header of the packet more conveniently. for example a packet with a 14 byte ethernet header could be started with an offset of 2 bytes to align the ip header to a 64 bit doubleword boundary. alternatively the offset may be used to easily add or strip an encapsulation header. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 149 the dma descriptor contains these parameters for each data buffer. a descriptor consists of two 64 bit double- words, dscr_a and dscr_b, that are stored in memory at consecutive locations aligned to a 16 byte boundary. figure 24 shows a descriptor. it can point to up to two buffers. the offset is only used at the start of a packet and normally applies to buffer a (since a new packet will always start a new descriptor). however, if the offset_b bit is set the offset is applied to the first b buffer in a packet (no offset is applied on buffer a so it will completely fill before the offset is applied at the start of buffer b). in addition to the fields describing the data the descriptor contains per-packet options that are passed to the interface, and status flags that can be written back into the descriptor by the interface. the options and status for the ethernet descriptors are summarized in section: ?option and flag bits for ethernet macs? on page 171 , those for the serial interface are summarized in section: ?control and flag bits for synchronous serial interface? on page 174 . the dma engines access the descriptors in cacheable-coherent memory, they must also be mapped this way in the cpu. figure 24: dma descriptor the descriptor also has three control bits. if the int bit is set then the dma channel will raise an interrupt when it has completed processing of the descriptor. the second control bit indicates if the buffer b details are valid, if this bit is clear the descriptor only has one associated buffer and the buffer b details are ignored (they are preserved when the status information is written back in to the descriptor, so could be used by software to store state information). the third control bit allows the offset field to be applied to the b buffer rather than the a buffer. figure 25 on page 150 shows a packet spanning three buffers. the start of the packet is offset from the start of the first buffer. following the last byte in the first buffer the packet continues to fill the entire second buffer. note that the offset is not applied in the continuation buffer. the packet ends in the third buffer, again the offset is not used. the packet length (which is only put in the dma descriptor associated with the first buffer) is the sum of the length used in the first buffer (i.e. the number of bytes from the offset to the end of the buffer), the full length of the second buffer, and the length used in the third buffer (i.e. the number of bytes from the buffer start to the end of the valid data). status size buffer a start address buffer a offset 63 0 packet size buffer b start address buffer b options dscr.a dscr.b length +0 +8 49 39 5 4 48 40 i n t v a l i d 50 o f f b 51 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 150 section 7: dma document 1250_1125-um100-r figure 25: packet spanning three buffers packet start address offset in bytes size (in cache blocks) l1 (in bytes) aligned to 32 byte block aligned to 32 byte block packet start address offset in bytes size (in cache blocks) l2 (in bytes) aligned to 32 byte block aligned to 32 byte block unused start address offset in bytes size (in cache blocks) l3 (in bytes) aligned to 32 byte block aligned to 32 byte block length = l1 + l2 + l3 in bytes packet user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 151 r ings and c hains each dma engine works from a set of descriptors. these may be organized either as a ring or a chain. figure 26: dma descriptor ring a descriptor ring is shown in figure 26 . each descriptor can point to two buffers and the next descriptor to use is in memory just after the current descriptor. the number of descriptors in the ring is configured when the ring is established. the dma engine will detect when it has reached the last descriptor (at the highest memory location) by checking the ring size, its successor is the descriptor at the lowest memory location, which is pointed to by the descriptor base register in the conf iguration block. the ring size can be from 1 to 65536 descriptors. the dma controller keeps track of its current position in the ring (initially the base). software passes ownership of descriptors (and the associated pair of buffers) to the controller by incrementing the count of the number of descriptors owned by the controller. writing to the count register adds the value written to the current count. the software may write the register at any time, the hardware prevents the potential conflict of the software incrementing as the controller decrements. there is no overflow protection on the count, so software should take care not to let the count pass 65535 descriptors owned by the dma controller. when the controller has finished with a descriptor it will return ownership by decrementing the count. if the descriptor interrupt bit is set an interrupt will be raised when ownership of the descriptor is returned. owned by dma engine current count ring size ring base buffer a buffer b size b size a descriptor 0 descriptor 1 . . . . . . . . descriptor ring_size-1 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 152 section 7: dma document 1250_1125-um100-r in a receive channel the interface flags the start of a packet when it sends data to the dma engine. in a transmit channel the length field for one packet allows the dma engine to directly determine when to expect the start of the next packet. in either case the dma engine will always advance to a new descriptor when a new packet is started. thus the first buffer in the pair can be used to point to small packet header buffers and the second buffer can be large and used for packet bodies. (this does not apply for the data mover since each transaction has its own descriptor.) the descriptor associated with the first buffer in a packet is treated specially. it contains per-packet options that are passed to the interface describing any special treatment that this packet should receive. once a packet has been completely transferred status information is written back into the first descriptor. received packets accumulate many status bits (described in section: ?option and flag bits for ethernet macs? on page 171 and section: ?control and flag bits for synchronous serial interface? on page 174 ), and additionally have the packet length written in to the descriptor. only the first descriptor of the packet is written and the sop flag bit will always be set. software can clear the status word in all descriptors used by the receive engine and then use the sop bit to identify descriptors that start packets. the sop bit will only be set when the full packet has been received. if the system revision indicates periph_rev3 or greater then the ethernet dma provides the option of overwriting the a_size field in the sop descriptor with the number of descriptors that were used by the received packet. if this is enabled (by setting the xtra_status bit in the dma_config1 register) and the standard descriptor format is used then the software will need to keep track of the a buffer size by some method other than reading the descriptor and will need to restore the a_size field before the descriptor can be used for a subsequent dma. for transmitted packets the only change in the status flags is that the sop bit is cleared, this can be used by software to detect the packet transmission has completed. if software does not make use of this feature the bandwidth used for descriptor management through the i/o bridge (and thus the latency for other accesses) can be reduced by disabling writing back the transmit status. in the ethernet dma engine the sop bit must always be set for the descriptor associated with the start of a packet, if the engine sees this bit clear in a descriptor that it believes should be the start of a packet then it will report a descriptor error and stop until software fixes the problem. if the sop bit is set then the options field of the transmit descriptor must be nonzero and is used to enable operations on the data as it is transmitted, if the sop bit is clear then the options field of the descriptor must be zero. if a channel is disabled, when it is enabled it will start from the descriptor pointed to by the base address. the count will not be changed. the cpu must either zero the count (by adding the twos-complement of its current value) or reorder the descriptors to put valid ones at the start of the ring or chain. if the system revision indicates periph_rev3 or greater then an ethernet transmit dma channel may be paused by setting the pause_channel_en bit in the dma_config1 register. this will pause the channel (but not the other transmit channel) at the next packet boundary. transmission will be resumed when the bit is cleared. this can be used for example by software to stop tranmission of a best-effort queue when the link partner indicates it is only able to buffer priority traffic. the ethernet interface will normally respond in hardware at the mac layer to pause frame flow control requests. however, if the system_revision indicates periph_rev3 or greater it can also be set to implement the pause at the dma layer (when this is done the interface may stop more slowly because of any packets buffered in the fifo between the dma engine and mac). if this option is enabled (by setting the channel_base_fc_en bit in the mac_vlantag register) then the fc_pause_en bit in the dma_config1 register determines if the channel is affected by pause frames or not. thus, provided the link partner is appropriately configured, the interface can be set to pause only one channel and allow the other (high priority) to continue even when the flow control is requested. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 153 figure 27: dma descriptor chain figure 27 shows a descriptor chain. each descriptor points to a single buffer, and contains a pointer to the next descriptor. ownership of descriptors is passed in the same way as ring mode, the count refers to the number of valid descriptors. the last valid descriptor must contain a link pointer to the location where software will place the next descriptor, when the count reaches zero the controller will remember the link value and fetch the new descriptor from that address when the count becomes non-zero. in both ring and chain modes reading the dma_cur_dscr_addr register gives address of the descriptor currently being processed and the current count of descriptors owned by the controller. if the count field in this register is non-zero then the address is of the descriptor that the controller is currently using. if the count is zero then the address is where the controller will fetch the next descriptor from when the count becomes non- zero. descriptor buffer size current c o u n t bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 154 section 7: dma document 1250_1125-um100-r u naligned b uffer d escriptor format for e thernet dma the alignment restrictions in the standard dma descriptors may be hard to work with in some existing systems and when a lot of scatter/gather operations are done to form packets for transmission. the dma engine in the ethernet/packet fifo interface on parts with system revision indicating periph_rev3 or greater supports a third descriptor format that allows arbitrary alignment of the start and end of buffers. the descriptors are slightly modified to support this and there are a number of restrictions. figure 28 on page 154 shows the descriptor format for the standard and unaligned buffer formats (a full definition is in table 102 and table 103 ). the changes and restrictions are: a buffer pointers always use the offset field (i.e. are a full 40 bit physical address). the size of the a buffer is specified in bytes in bits 21:8 of the dscr_b (where the buffer b address is in the standard format). note that the descriptor field must be set to the size of the data plus the low 5 bits of the start address, so the maximum buffer size for arbitrary alignment is 16k-32 bytes. the a_size field is not used and can therefore always be used for the optional extra status information. no b buffers are available. only ring mode can be used. the packet length, status, interrupt and options fields work as in the standard mode. the descriptor format is selected separately for each dma channel. the unaligned mode is particularly useful for the transmit descriptors when packet manipulations are performed, but the standard mode may be more useful for the receive side where there is more control of the buffer locations and advantage can be taken of a and b buffers. figure 28: standard and unaligned buffer dma descriptors status size (lines) buffer a start address buffer a offset 63 0 packet size (lines) buffer b start address buffer b options dscr.a dscr.b length +0 +8 49 39 5 4 48 40 i n t v a l i d 50 o f f b 51 packet size buffer a options dscr.b length +8 status (optional start address buffer a dscr.a +0 i n t r s r v standard unaligned buffer standard unaligned buffer (optional status) status) (bytes) 8 21 reserved r s r v user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 155 this format is useful for scatter/gather operations, in particular when transmit packets are being composed and headers inserted or removed. care must be taken since the format allows for very low performance settings: for example if all buffers are only 3 bytes then the overhead of fetching descriptors will completely dominate the data transfers. when the unaligned buffer format is used for packet reception and the start and end of a buffer are not aligned to a cache block boundary the dma engine provides two options. the high performance option is for the interface to always write full cache lines (using the zbbus writeinvalidate command) and therefore overwrite the bytes before and after the buffer with unpredictable data. the lower performance option is to use a read-modify-write to ensure only the valid bytes are modified, this will have a tendency to back up the read- modify-write queue (since the write must be queued for the read latency) and should therefore be avoided if possible. dma c oherence and c ache o ptions all dma transfers are coherent with the cpu l1 caches, the l2 cache and memory. on reads the latest copy of the data will be retrieved from the current owner and on writes any existing copies of the data will be invalidated or updated. the dma controllers can drive a l2-cache request attribute with transfers. this will cause the data to be allocated in the l2 cache if the cache misses (if the l2 cache hits it will always be updated regardless of the attribute). the channel configuration sets how many blocks from the start of a packet should be marked for allocation in the l2 cache (this can be set larger than the maximum packet size to have complete packets sent to the cache). the l2 is still being used as a cache, the data still has a memory address and can be evicted from the cache to memory if the l2 replacement algorithm requires it. the network and serial port interfaces have data buffers that are aligned to a cache block boundary and are an integral number of cache blocks in size, so on incoming transfers they never need to perform read-modify- write operations (the actual packet data may be offset from the start of the buffer and may finish short of the end of the buffer, but the dma will always be padded out to a full cache line at each end). the writes to memory are always made with the write-invalidate command, which invalidates any copies of the block in l1 caches, and returns ownership of the block to the l2 cache and memory system (the default owner). in the standard aligned buffer mode, or the unaligned buffer mode with writeinvalidate, device driver code has to take care not to store any additional data in the cache block that a buffer starts or ends in. particular care must be taken with buffer link pointers and buffer header information at the start of the buffer. even if an offset is applied in the descriptor the buffer is still aligned and any bytes before the offset will be overwritten with unpredictable values when a packet is received. in the standard mode the end of the buffer is always aligned so there is not a problem, but in the writeinvalidate unaligned mode if the buffer has an unaligned end the bytes for the rest of the cache block that c ontain the end of the buffer will be overwritten with unpredictable data. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 156 section 7: dma document 1250_1125-um100-r dma c onfigurations there are many ways that the dma structure can be configured allowing use with many existing systems. the cpu should always use the cacheable coherent mode to access descriptors and buffers to allow the system to take care of the coherence and avoid the need for software to manage the l1 caches. the dma engines access descriptors and buffers through the i/o bridge which will always use cacheable coherent accesses to memory addresses and uncacheable (accelerated) accesses for other addresses. consideration should be given to the descriptors and their access pattern. in memory space all reads from the controller will be of a full cache block, so if the system were configured to use chain mode descriptors and 32 byte buffers the number of memory accesses fetching descriptors will equal the number of memory accesses for data. the system performance will be lower than expected because half of the bandwidth is consumed by descriptor management. in a new system it is recommended that the descriptors be organized in ring mode and the controller be permitted to prefetch descriptors (tdx_en set in the dma_config0 register). this reduces the descriptor fetch overhead compared to the number of buffer transfers. in most cases receive descriptors should also be marked for allocation in the l2 cache (dscr_l2ca set in the dma_config1 register) since they are a shared resource and they are expected to be accessed over a short time period by the dma controller (twice for the header descriptor which will be updated with the length and status information) and the cpu. when the dma controller updates a descriptor it must use a read-modify-write operation. if software does not need the sop bit to be cleared in transmit descriptors, the read-modify-write can be avoided by setting the no_dscr_updt bit in the dma_config1 register. if this is done, transmit descriptors do not need to be marked for l2 cache allocation by the dma engine, the cpu will have them cacheable in both l1 and l2 caches so the dma engine will read them directly from the cache and it never writes them back. the buffer size can also be increased to reduce the descriptor overhead. while the hardware does support buffers as small as 32 bytes (and these may be ideal as header buffers) the system becomes more efficient as the buffer size is increased. in the transmit channel the tbx_en bit should be set in the dma_config0 register to allow the controller to prefetch buffer data whenever possible. if this bit is set the controller will mostly fetch pairs of cache blocks back to back and is more likely to make use of an open page in the sdram. on the receive side cache block writes are posted as soon as the data is available and this bit has no effect. the most sensitive interface is the transmit side of the ethernet (or packet fifo in gmii mode). once transmission of a packet has started there must be no interruptions. this is achieved by using a small data fifo in the interface and priority in the memory controller. the data fifo is intended just for speed match buffering. there is a threshold which sets how much of a packet must be in the fifo for transmission to begin, since the fifo drains at a constant rate this directly translates into the memory latency that will be covered by the buffer. in general the fifo will fill quickly (particularly when tbx_en allows fetching of pairs of cache blocks), and drain during any high latency memory reads. the worst case is when a new descriptor must be fetched during a packet transmission, since the next block of data cannot be fetched until the descriptor read completes. to allow this to work with a relatively small fifo the memory controller implements a priority scheme. this is needed because the cpus and data mover can easily swamp the memory controller (they can access data at much higher bandwidths and frequencies than the i/o dma engines, so this is an ideal place for priority to protect the low request rate interface from being dominated by a high request rate one). any reads from the i/o bridge 1 are prioritized over other memory accesses, if they conflict with a write to memory the priority of the write is also raised. in addition some of the memory controller buffers can be reserved for use by the i/o bridge 1 dma engines. the priority scheme is described in section: ?memory controller architecture? on page 104 . if memory is accessed across the hypertransport there is no priority scheme and the transmit fifo is likely to underflow during packet transmission (however, because the writes are posted it should be possible to receive into buffers in a memory across the hypertransport fabric). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 157 e thernet and s erial dma e ngines the ethernet and serial dma engines are identical except for using different per-packet options and status flags. each channel works as described above using either a ring or a chain. the dma engines have the restriction that neither the descriptors nor data buffers may be at an address serviced by i/o bridge 1, the system behavior is undefined if this is violated. in practice this restriction just rules out dma access from the ethernet or serial dma to the generic bus, since the other devices connected through i/o bridge 1 are all based on control registers and are unreasonable dma targets. figure 5 on page 9 shows the devices that are behind i/o bridge 1. both ethernet and serial dma controllers are connected to the zbbus through i/o bridge 1. in the direction from the zbbus to the devices there is a separate command queue for read and writes to peripheral registers and response queue for data returning to descriptor or buffer dma read requests. this ensures that the dma traffic is not blocked by requests to slow peripherals (such as a slow device on the generic bus). in the direction towards the zbbus it is important that if a status read reports completion of a command the response does not pass that command, so read and write requests from the dma engine and responses to register reads are held in a single queue. generic bus responses do not need this ordering and are given their own return queue. each channel has an interrupt associated with it. in the ethernet interface the status for the two receive and two transmit dma channels are combined into the mac_status register for the interface (see table 182 on page 309 ). the serial interface transmit and receive channel status are combined into the ser_status register for each channel that can be read to determine the interrupt cause (see table 240 on page 356 ). reading the status will clear all bits in the status register and clear the interrupt. d escriptor c ount w atermarks the count of descriptors owned by the dma controller is compared to two watermark registers. the high watermark is set in the high_watermark field of the dma_config0 register, and the low watermark is set in the low_watermark field. it is expected that the high watermark is programmed to a larger value than the low watermark. the cpu can opt to be interrupted when the descriptor count falls below either (or both) watermarks. in a transmit engine setting the low watermark register to 1 and disabling the high watermark interrupt will give an interrupt when all queued transmissions are complete. in a receive engine the interface can be configured to use automatic flow-control. if this is enabled then when the number of descriptors falls below the low watermark the interface will be signalled to use flow control to apply back pressure, which will only be removed when sufficient descriptors have been supplied to push the count above the high watermark. if the engine is configured to interrupt the cpu when the descriptor count falls below the high watermark, software has a chance to allocate more receive descriptors before flow control is asserted. if automatic flow control is enabled and the high watermark is smaller than the low watermark the behavior of the engine is unpredictable. the watermark based flow control will not activate until after buffers have been added to the descriptor queue for the first time, so the link will not be jammed as the interface comes out of reset. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 158 section 7: dma document 1250_1125-um100-r the watermark status, which is used to raise an interrupt, is continually updated. if the number of descriptors falls below a watermark just as the cpu is doing a write to the count register to increase the number of descriptors owned by the dma engine, the interrupt line may be briefly asserted but all status bits will be clear when the cpu has entered the interrupt service routi ne and reads the status register. software should be written to work correctly if these spurious interrupts occu r (or only add buffers in the isr or with the interrupts disabled). if the receive dma engine runs out of descriptors during a packet the tail of the packet is lost and the dscr_err bit is set in the receive status. in this case the status includes enough information for the software to compute the size of data actually transferred, but in most cases the packet will just be dropped. if the receive engine is out of descriptors when the start of a packet is received the whole packet is dropped and the interface will signal a packet dropped interrupt. in either case packet reception will resume with the start of the first packet received after the count has been written to make more descriptors available. the ethernet receive dma channels count the packets that are dropped because the channel is out of descriptors when the start of packet is received, on parts with system revision indicating periph_rev3 or greater this count can be read from the dma_oodpktlost register. any write to this register (regardless of data) will zero the count. c ompletion i nterrupts the controller has a packet counter and will generate an interrupt after transferring a configurable number of packets. this is of most use in the receive channel. if the interrupt count is set to one then an interrupt will be raised after every packet. since this can swamp the system with interrupts, the count would typically be set higher and the receive interrupt service routine will be written to accept a batch of packets. in order to avoid imposing a high delay before packets are serviced when they are arriving at a low rate, the interrupt can also be raised by a timer. the timer starts counting when the first packet reception is complete and will increment every 768 cpu clocks (i.e. the counter is clocked at cpuclock/(3*256)). if the interrupt has not been raised because the packet count threshold has been reached it will be forced when the timer has counted to a programmed limit. reading the interface interrupt status register will clear both the packet counter and resets the timer, both will remain at zero until the next packet transfer is complete. the device driver must be written based on this behavior and should handle (or queue) any interrupts that are marked when the status is read. the completion interrupts are also available for transmit interfaces. in this case the counter will increment when a packet transmission has completed, and the timer will start running when the first transmission has completed. this could be used to detect the transmitter being unable to send for an unacceptably long period. the interrupt is cleared by reading the channel's interrupt status register, this disables the timer and zeros the received packet count preparing the system for the next batch of packets. on parts with system revision indicating periph_rev3 or greater the current value of the received packet count can be read from the dma_oodpktlost register. e xplicit d escriptor i nterrupts the descriptors include a flag to cause the controller to raise an interrupt when it has finished using the marked descriptor. the flag can be set on the last descriptor in a batch of packets that are queued for transmission, software will then receive notification when they have all been sent even if more packets have been queued. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 159 asic m ode t ransfers the ethernet and serial interface receive dma engines have a special "asic mode" that enables received packets to be passed through an asic on the hypertranspor t fabric or pci bus. this is in addition to just sending the packet by address to an i/o destination. it allows connection of a simple asic that is logically inserted into the path from the interface to memory. the asic mode is intended for use in configurations where there is an assist asic on the hypertransport or pci through which some or all of a packet must be passed. examples include header classification engines and encryption/decryption devices. figure 29 shows an example packet flow. figure 29: packet reception flow using dma asic mode asic mode is enabled by setting the asic_xfr_en bit in the dma_config1 register. the normal dma descriptors are fetched for each packet. rather than sending the packet header to the first buffer in the descriptor, the packet is directed to the address range set in the dma_asic_addr register. the asicxfr_size is set to the number of cache lines of the packet that should be sent to the asic; if there is an offset specified this is one less than the maximum number of cache lines that should be sent to the asic address range (i.e. if the asicxfr_size is 0 and asci_xfr_en is set then one cache line will be sent to the asic). the size sent to the asic must match the size set for the first descriptor or behavior of the engine is undefined. if the packet length is shorter than the size specified by the asicxft_size field then the entire packet is sent to the asic, otherwise after the configured size has been sent to the asic the dma controller advances to the second buffer in the descriptor and will transfer to memory in the normal way. if the packet spans to subsequent descriptors they will be used to send the data to memory; data is only directed to the asic following a start of packet. mem controller ht asic dma network bcm1250 phy ddr sdram BCM1125/h bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 160 section 7: dma document 1250_1125-um100-r the pre_addr_en bit enables prepending of the dscr_a doubleword of the dma descriptor to the data sent to the asic. if this bit is set then the offset in the dma descriptor must be set to 8 (or greater than 8) and the asicxfr_size must be adjusted as outlined above. the descriptor information can be used by the asic to write the processed data back into memory at the address specified in the original dma descriptor. since the entire descriptor doubleword is sent the asic has access to the size of the buffer, and flags can be passed from the software to the asic by setting them up in the status field. (this field is not used by the dma controller, so can contain any value when it reads the descriptor. however, the descriptor in memory will be updated by the dma engine on completion of the packet reception, so any value passed from software to the asic in these bits will be overwritten). note that the offset is not sent to the asic, these 5 bits are unpredictable. the asic does not receive the packet status information, except for an error indication described below. cache blocks of the packet will be sent to the asic tagged by address according to figure 30 and table 90 . figure 30: asic mode address generation the dma_asic_addr specifies the base address for a 1 mb region of memory. the first cache block in a packet (with the descriptor prepended if enabled) will be sent to the start of packet (sop) address, subsequent blocks are sent to the middle of packet (mop) address range and the last cache block in the packet will be set to either the end of packet (eop) address or the eop/error address. the block sent to the eop address may contain less than a full cache block of valid data, the byte count indicates the number of valid bytes which will be packed towards the low memory address end of the block sent. asic base addr rx dma block 5 17 18 20 39 channel type byte ignored 19 15 16 10 11 number 40 unused in block address count table 90: address used for asic mode transfers bits name description 4:0 these bits are not present, since a full cache line is always transferred. 10:5 ignored ignore 15:11 byte_count in eop packets this is set to the number of valid bytes in the block. this field is ignored in sop or mop blocks. there can be from 1-32 valid bytes, the field is 0 to indicate 32 bytes valid. 17:16 type set to the position of the block in the packet. 00: middle of packet (mop). 01: start of packet (sop), the block includes the prepended descriptor if enabled. 10: end of packet with no errors (eop), the byte_count field indicates the number of valid bytes in the cache block. 11: end of packet with errors (eop/error), the byte_count field indicates the number of valid bytes in the cache block. 19:18 channel set to the dma channel number. 39:20 base set to the base address from bits [39:20] of the dma_asic_addr register. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 161 figure 31 shows a full packet being sent using asic mode. in this case the asicxfr_size is set to its maximum value (which is greater than the maximum packet size) ensuring the complete packet is sent to the asic. figure 31: sending the whole packet in asic mode the first cache block is sent to the sop address, formed by adding the channel number bits and the 01 sop code bits to the base address. this line includes the prepended first doubleword of the dma descriptor (dscr_a) in the lowest 8 bytes. subsequent blocks are sent to the mop address until the last block. the final block is sent to the eop address formed by adding the channel number bits, the 10 eop code and the number of valid bytes to the base address. the valid byte count is needed because a full 32 byte block is always sent. once the complete packet has been sent the dma controller will write the length and status flags back into the descriptor in the normal way. the next descriptor will be fetched for the next packet (so the b buffer is never used). the asic can process the packet, and write data back to memory at the address given in the prepended dscr_a. the asic needs a way to inform the cpu that its processing is complete. the dma controller will generate the end of packet (or completion or watermark) interrupt when it has sent the full packet to the asic and has written the status back into the descriptor. there is a latency in the buffering between the interface and the asic, the asic will take time to process the packet and there will be latency writing the result back to memory, so any interrupts from the dma controller are likely to be seen by the cpu before the asic has completed processing the packet. a simple way for the asic to do this is to send a hypertransport interrupt message after writing the last data. the hypertransport protocol, and host bridge will ensure that the ordering is maintained and the cpu does not receive the interrupt until the data of the write is visible in the coherency protocol. d s c r a 8 32 32 32 32 32 32 valid sop mop mop mop mop eop base + 256k* ch + 64k * 0 sent to sent to base + 256k * ch + 64k *1 base + 256k * ch + 64k * 2 + 2048 * valid asic_xfr_en=1 pre_addr_en=1 asic_xfr_size=max (lff) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 162 section 7: dma document 1250_1125-um100-r figure 32 illustrates the asic mode being used to pass only the header of a packet (for example for classification). the asicxfr_size is set to the number of header cache blocks (typically 2, causing 64 bytes of header to be sent to the asic with no prepended descriptor or 1 causing 56 bytes of header to be sent with the prepended descriptor). the dscr_a size must be set to the same value. figure 32: sending a packet header in asic mode the sop address is still used for the first block in the packet, and mop for subsequent blocks (if the packet is only two blocks the second will be sent to the eop address). once the header size has been sent to the asic address the dma controller advances to buffer b and sends the rest of the packet into memory in the normal way, when it is done it will write the length and flags back into the descriptor. the asic can perform its header processing and write results and the header back using the buffer a address. if cpu intervention is required an asic on the hypertransport fabric could opt to write the results and header back with hypertransport isochronous writes, which causes the data to be allocated in the l2 cache. if the results are greater than 8 bytes (the offset that was specified to allow the dscr_a to be prepended) the actual buffer size may need to be greater than indicated in the descriptor, since the size given in the descriptor must match the size sent to the asic. the system software must manage this difference by allocating the larger buffer and adjusting the size in the descriptors. d s c r a 8 32 32 32 32 32 32 valid sop sent to buffer pointed to by dscr b sent to base + 256k * ch + 64k *1 asic_xfr_en=1 pre_addr_en=1 asicxfr_size=2 dscr a size=2 mop sent to base + 256k * ch + 64k *0 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 163 e thernet and s erial dma c ontrol r egisters the bcm1250 has macs 0, 1 and 2. the BCM1125/h has macs 0 and 1. accesses made to the address range allocated to a nonexistant mac may cause all macs to exhibit unpredictable behavior. table 91: ethernet and serial dma configuration register 0 dma_config0_mac_0_rx_ch_0 - 00_1006_4800 dma_config0_mac_0_tx_ch_0 - 00_1006_4c00 dma_config0_mac_0_rx_ch_1 - 00_1006_4900 dma_config0_mac_0_tx_ch_1 - 00_1006_4d00 dma_config0_mac_1_rx_ch_0 - 00_1006_5800 dma_config0_mac_1_tx_ch_0 - 00_1006_5c00 dma_config0_mac_1_rx_ch_1 - 00_1006_5900 dma_config0_mac_1_tx_ch_1 - 00_1006_5d00 dma_config0_mac_2_rx_ch_0 - 00_1006_6800 dma_config0_mac_2_tx_ch_0 - 00_1006_6c00 dma_config0_mac_2_rx_ch_1 - 00_1006_6900 dma_config0_mac_2_tx_ch_1 - 00_1006_6d00 dma_config0_ser_0_rx - 00_1006_0400 dma_config0_ser_0_tx - 00_1006_0480 dma_config0_ser_1_rx - 00_1006_0800 dma_config0_ser_1_tx - 00_1006_0880 bits name default description 0 drop 1'b0 set to cause all packets to the channel to be dropped. mac receive channels only, setting this bit in other channels causes undefined behavior. 2:1 dscr_type 2'b0 this field sets the descriptor format: 00 - descriptor ring, standard aligned buffer format. 01 - descriptor chain, standard aligned buffer format. 10 - descriptor ring, unaligned buffer format, writeinvalidate overwrites a full cache block at start/end of a buffer. 11 - descriptor ring, unaligned buffer format, read-modify-write at start/end of unaligned buffer. formats 10 and 11 are only supported by the ethernet dma engine and only if the system revision indicates periph_rev3 or greater. 3 eop_int_en 1'b0 set to enable interrupt at end of packet. the interrupt will be generated when the number of packets specified in int_pktcnt have been received, or if the receive interrupt timer has timed out. see section: ?completion interrupts? on page 158 . 4 hwm_int_en 1'b0 set to enable an interrupt when the number of descriptors owned by the dma controller falls below the high watermark. 5 lwm_int_en 1'b0 set to enable an interrupt when the number of descriptors owned by the dma controller falls below the low watermark. the receiver will assert flow control when the number of descriptors falls below this watermark. 6 tbx_en 1'b0 set to cause the transmit dma engine to fetch two 32 byte blocks at a time (increasing the open page hit rate in the sdram). clear to only fetch one block at a time. the tx_wr_thrsh threshold must be set to match the fetch size. mac transmit channels only, setting this bit in other channels causes undefined behavior. if system revision indicates a peripheral revision earlier than periph_rev3 then when this bit is set the buffer size should be a multiple of 64 bytes, if the system revision indicates periph_rev3 or greater there is no restriction. 7 tdx_en 1'b0 set in ring mode to allow the dma engine to fetch two descriptors at a time. clear if the engine should use 16 byte fetches to get a single descriptor. if this bit is set and there is only a single descriptor available then the invalid prefetched data is discarded. it is recommended that this bit is set in any high bandwidth dma channels. 15:8 int_pktcnt 8'b0 this sets the number of packets that must be received before an end of packet interrupt is raised. see section: ?completion interrupts? on page 158 . 31:16 ringsz 16'b0 when the channel is operating in ring mode this sets the number of descriptors in the ring. it should only be changed when the channel is disabled. if this field is set to 0 the ring will contain 65536 descriptors. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 164 section 7: dma document 1250_1125-um100-r 47:32 high_watermark 16'b0 this specifies the high watermark for generating an interrupt to the cpu based on the number of descriptors. if the mac receiver is asserting flow control and the number of descriptors rises above this watermark it will remove the flow control. 63:48 low_watermark 16'b0 this specifies the low watermark for generating an interrupt to the cpu based on the number of descriptors. the mac receiver will assert flow control when the number of descriptors falls below this watermark. table 91: ethernet and serial dma configuration register 0 (cont.) table 92: ethernet and serial dma configuration register 1 dma_config1_mac_0_rx_ch_0 - 00_1006_4808 dma_config1_mac_0_tx_ch_0 - 00_1006_4c08 dma_config1_mac_0_rx_ch_1 - 00_1006_4908 dma_config1_mac_0_tx_ch_1 - 00_1006_4d08 dma_config1_mac_1_rx_ch_0 - 00_1006_5808 dma_config1_mac_1_tx_ch_0 - 00_1006_5c08 dma_config1_mac_1_rx_ch_1 - 00_1006_5908 dma_config1_mac_1_tx_ch_1 - 00_1006_5d08 dma_config1_mac_2_rx_ch_0 - 00_1006_6808 dma_config1_mac_2_tx_ch_0 - 00_1006_6c08 dma_config1_mac_2_rx_ch_1 - 00_1006_6908 dma_config1_mac_2_tx_ch_1 - 00_1006_6d08 dma_config1_ser_0_rx - 00_1006_0408 dma_config1_ser_0_tx - 00_1006_0488 dma_config1_ser_1_rx - 00_1006_0808 dma_config1_ser_1_tx - 00_1006_0888 bits name default description 0 hdr_cf_en 1'b0 if this bit is set then the l2_cacheable bit will be asserted during header transfers to cause the l2 cache to be allocated. 1 asic_xfr_en 1'b0 set to enable special support for transferring packets to an asic on the hypertransport fabric (or pci bus). 2 pre_addr_en 1'b0 set when asic_xfr_en is set to enable prepending of the dma descriptor to the packet sent to the asic. 3 flow_ctl_en 1'b0 set to cause the controller to send a flow control request to the interface when the descriptor count falls below the low watermark, and only remove the request when the count goes above the high watermark. mac receive channels only, setting this bit in other channels causes undefined behavior. 4 no_dscr_updt 1'b0 set to prevent the descriptor being written with the status at the end of a packet transfer, saving bandwidth through the bridge. (transmit channels only.) 5 dscr_l2ca 1'b0 this bit sets the l2 cacheability for descriptors. if it is set the l2ca bit will be set in descriptor requests, causing them to be cached in the l2 cache. if clear the descriptors will not be allocated in the l2 on a miss. 6 (rx) xtra_status (tx) cpu_pause_en 1'b0 ethernet receive channels only: this bit should only be set for the ethernet receive engine and only if the system revision indicates periph_rev3 or greater. if this bit is set the a_size field will be overwritten with additional status information in the start of packet descriptor. ethernet transmit channels only: this bit should only be set for the ethernet transmit engine and only if the system revision indicates periph_rev3 or greater. if this bit is set the channel will pause at the end of the current packet and will resume only when the bit is cleared. 7 fc_pause_en 1'b0 ethernet transmit channels only: this bit should only be set for the ethernet transmit engine and only if the system revision indicatess periph_rev3 or greater. if this bit is set and the interface is set for dma channel based flow control (ch_base_fc_en bit set in the mac_vlantag register) then this channel will be paused by a flow control frame, if this bit is clear and the interface is set for dma channel based flow control the channel will not be paused by a flow control frame. if the interface is not configured for dma channel based flow control this bit is ignored. 15:8 reserved 8'b0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 165 20:16 zero 5'b0 these bits must be zero. 29:21 hdr_size 9'b0 this sets the header length in cache blocks. it sets the number of cache blocks for which the l2 cacheable attribute will be attached if hdr_cf_en is asserted. this count is taken from the start of the buffer (the first cache line contains only 32 - offset bytes from the packet). 31:30 reserved 2'b0 reserved 36:32 zero 5'b0 these bits must be zero. 45:37 asicxfr_size 9'b0 this field sets the size (in cache lines) of the portion of the packet that will be sent to the asic if asic_xfr_en is set. packets shorter than this size will be sent in their entirety using the eop protocol described in section: ?asic mode transfers? on page 159 to signal the packet end. care must be taken to adjust the number set here when an offset is used (which must be the case if the pre_addr_en bit is set). the number of cache lines sent to the asic will be: offset zero: the number in this field. (if this field is zero then one cache line is transferred.) offset nonzero: one greater than the number in this field. 47:46 reserved 2'b0 reserved 63:48 int_timeout 16'b0 this field sets the timeout for interrupt generation. see section: ?completion interrupts? on page 158 . if this field is zero then timing of the assertion of the eop_timer interrupt flag is unpredictable. table 92: ethernet and serial dma configuration register 1 (cont.) dma_config1_mac_0_rx_ch_0 - 00_1006_4808 dma_config1_mac_0_tx_ch_0 - 00_1006_4c08 dma_config1_mac_0_rx_ch_1 - 00_1006_4908 dma_config1_mac_0_tx_ch_1 - 00_1006_4d08 dma_config1_mac_1_rx_ch_0 - 00_1006_5808 dma_config1_mac_1_tx_ch_0 - 00_1006_5c08 dma_config1_mac_1_rx_ch_1 - 00_1006_5908 dma_config1_mac_1_tx_ch_1 - 00_1006_5d08 dma_config1_mac_2_rx_ch_0 - 00_1006_6808 dma_config1_mac_2_tx_ch_0 - 00_1006_6c08 dma_config1_mac_2_rx_ch_1 - 00_1006_6908 dma_config1_mac_2_tx_ch_1 - 00_1006_6d08 dma_config1_ser_0_rx - 00_1006_0408 dma_config1_ser_0_tx - 00_1006_0488 dma_config1_ser_1_rx - 00_1006_0808 dma_config1_ser_1_tx - 00_1006_0888 bits name default description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 166 section 7: dma document 1250_1125-um100-r table 93: ethernet and serial dma descriptor base address register dma_dscr_base_mac_0_rx_ch_0 - 00_1006_4810 dma_dscr_base_mac_0_tx_ch_0 - 00_1006_4c10 dma_dscr_base_mac_0_rx_ch_1 - 00_1006_4910 dma_dscr_base_mac_0_tx_ch_1 - 00_1006_4d10 dma_dscr_base_mac_1_rx_ch_0 - 00_1006_5810 dma_dscr_base_mac_1_tx_ch_0 - 00_1006_5c10 dma_dscr_base_mac_1_rx_ch_1 - 00_1006_5910 dma_dscr_base_mac_1_tx_ch_1 - 00_1006_5d10 dma_dscr_base_mac_2_rx_ch_0 - 00_1006_6810 dma_dscr_base_mac_2_tx_ch_0 - 00_1006_6c10 dma_dscr_base_mac_2_rx_ch_1 - 00_1006_6910 dma_dscr_base_mac_2_tx_ch_1 - 00_1006_6d10 dma_dscr_base_ser_0_rx - 00_1006_0410 dma_dscr_base_ser_0_tx - 00_1006_0490 dma_dscr_base_ser_1_rx - 00_1006_0810 dma_dscr_base_ser_1_tx - 00_1006_0890 bits name default description 3:0 zero 4'b0 these bits must be zero. 39:4 base 36'b0 this is the base address of the descriptor ring, or the pointer to the first descriptor in a chain. this register must only be changed when the channel is disabled. when a channel is disabled and enabled again it will start fetching descriptors from this address. 64:40 reserved 24?b0 reserved table 94: asic mode base address dma_asic_addr_mac_0 - 00_1006_4418 dma_asic_addr_mac_1 - 00_1006_5418 dma_asic_addr_mac_2 - 00_1006_6418 dma_asic_addr_ser_0 - 00_1006_0598 dma_asic_addr_ser_1 - 00_1006_0998 bits name default description 19:0 zero 20'b0 these bits must be zero. 39:20 base 36'b0 this is the base of the asic address space. 64:40 reserved 24?b0 reserved table 95: descriptor count register dma_dscr_cnt_mac_0_rx_ch_0 - 00_1006_4818 dma_dscr_cnt_mac_0_tx_ch_0 - 00_1006_4c18 dma_dscr_cnt_mac_0_rx_ch_1 - 00_1006_4918 dma_dscr_cnt_mac_0_tx_ch_1 - 00_1006_4d18 dma_dscr_cnt_mac_1_rx_ch_0 - 00_1006_5818 dma_dscr_cnt_mac_1_tx_ch_0 - 00_1006_5c18 dma_dscr_cnt_mac_1_rx_ch_1 - 00_1006_5918 dma_dscr_cnt_mac_1_tx_ch_1 - 00_1006_5d18 dma_dscr_cnt_mac_2_rx_ch_0 - 00_1006_6818 dma_dscr_cnt_mac_2_tx_ch_0 - 00_1006_6c18 dma_dscr_cnt_mac_2_rx_ch_1 - 00_1006_6918 dma_dscr_cnt_mac_2_tx_ch_1 - 00_1006_6d18 dma_dscr_cnt_ser_0_rx - 00_1006_0418 dma_dscr_cnt_ser_0_tx - 00_1006_0498 dma_dscr_cnt_ser_1_rx - 00_1006_0818 dma_dscr_cnt_ser_1_tx - 00_1006_0898 bits name default description 15:0 count 16'b0 this is the number of descriptors owned by the dma engine. reads will return the number of descriptors owned (count in figure 26 on page 151 and figure 27 on page 153 ). data that is written to this register will be added to the count (assigning that number of additional descriptors to the controller). the count is a 16 bit unsigned number, there is no overflow protection. software should ensure it does not unintentionally cause the count to wrap. 64:16 reserved 48?b0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 167 table 96: current descriptor a debug register dma_cur_dscr_a_mac_0_rx_ch_0- 00_1006_4820 dma_cur_dscr_a_mac_0_tx_ch_0- 00_1006_4c20 dma_cur_dscr_a_mac_0_rx_ch_1- 00_1006_4920 dma_cur_dscr_a_mac_0_tx_ch_1- 00_1006_4d20 dma_cur_dscr_a_mac_1_rx_ch_0- 00_1006_5820 dma_cur_dscr_a_mac_1_tx_ch_0- 00_1006_5c20 dma_cur_dscr_a_mac_1_rx_ch_1- 00_1006_5920 dma_cur_dscr_a_mac_1_tx_ch_1- 00_1006_5d20 dma_cur_dscr_a_mac_2_rx_ch_0- 00_1006_6820 dma_cur_dscr_a_mac_2_tx_ch_0- 00_1006_6c20 dma_cur_dscr_a_mac_2_rx_ch_1- 00_1006_6920 dma_cur_dscr_a_mac_2_tx_ch_1- 00_1006_6d20 dma_cur_dscr_a_ser_0_rx - 00_1006_0420 dma_cur_dscr_a_ser_0_tx - 00_1006_04a0 dma_cur_dscr_a_ser_1_rx - 00_1006_0820 dma_cur_dscr_a_ser_1_tx - 00_1006_08a0 read only bits name default description 63:0 cur_a 64'b0 the current descriptor first double word can be read from this register (intended for debugging only). table 97: current descriptor b debug register dma_cur_dscr_b_mac_0_rx_ch_0- 00_1006_4828 dma_cur_dscr_b_mac_0_tx_ch_0- 00_1006_4c28 dma_cur_dscr_b_mac_0_rx_ch_1- 00_1006_4928 dma_cur_dscr_b_mac_0_tx_ch_1- 00_1006_4d28 dma_cur_dscr_b_mac_1_rx_ch_0- 00_1006_5828 dma_cur_dscr_b_mac_1_tx_ch_0- 00_1006_5c28 dma_cur_dscr_b_mac_1_rx_ch_1- 00_1006_5928 dma_cur_dscr_b_mac_1_tx_ch_1- 00_1006_5d28 dma_cur_dscr_b_mac_2_rx_ch_0- 00_1006_6828 dma_cur_dscr_b_mac_2_tx_ch_0- 00_1006_6c28 dma_cur_dscr_b_mac_2_rx_ch_1- 00_1006_6928 dma_cur_dscr_b_mac_2_tx_ch_1- 00_1006_6d28 dma_cur_dscr_b_ser_0_rx - 00_1006_0428 dma_cur_dscr_b_ser_0_tx - 00_1006_04a8 dma_cur_dscr_b_ser_1_rx - 00_1006_0828 dma_cur_dscr_b_ser_1_tx - 00_1006_08a8 read only bits name default description 63:0 cur_b 64'b0 the current descriptor second double word can be read from this register (intended for debugging only). table 98: current descriptor address register dma_cur_daddr_mac_0_rx_ch_0 - 00_1006_4830 dma_cur_daddr_mac_0_tx_ch_0 - 00_1006_4c30 dma_cur_daddr_mac_0_rx_ch_1 - 00_1006_4930 dma_cur_daddr_mac_0_tx_ch_1 - 00_1006_4d30 dma_cur_daddr_mac_1_rx_ch_0 - 00_1006_5830 dma_cur_daddr_mac_1_tx_ch_0 - 00_1006_5c30 dma_cur_daddr_mac_1_rx_ch_1 - 00_1006_5930 dma_cur_daddr_mac_1_tx_ch_1 - 00_1006_5d30 dma_cur_daddr_mac_2_rx_ch_0 - 00_1006_6830 dma_cur_daddr_mac_2_tx_ch_0 - 00_1006_6c30 dma_cur_daddr_mac_2_rx_ch_1 - 00_1006_6930 dma_cur_daddr_mac_2_tx_ch_1 - 00_1006_6d30 dma_cur_daddr_ser_0_rx - 00_1006_0430 dma_cur_daddr_ser_0_tx - 00_1006_04b0 dma_cur_daddr_ser_1_rx - 00_1006_0830 dma_cur_daddr_ser_1_tx - 00_1006_08b0 read only bits name default description 39:0 dscr_addr 40'b0 the current descriptor address can be read from this field. if count is nonzero the address is the descriptor being used. if count is zero the address is where the next descriptor will be fetched from. 55:40 count 16'b0 the current count of descriptors owned by the dma engine can be read from this field. (it provides the same information as reading the dma_dscr_count register). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 168 section 7: dma document 1250_1125-um100-r 56 ch_pause_on 1'b0 only valid if system revision indicates periph_rev3 or greater and only valid for ethernet transmit channels. this bit is set if the channel has paused because the cpu_pause_en bit is set in the dma_config1 register or a flow control frame has been received the fc_pause_en bit is set in the dma_config1 register and the ch_base_fc_en bit is set in the mac_vlantag register. note that this bit is set when the channel is actually pausing, so when the cpu_pause_en bit is set the ch_pause_en will remain clear until any packet in progress has been sent and the channel is stopped between packets. 63:57 reserved 7'b0 reserved table 98: current descriptor address register (cont.) dma_cur_daddr_mac_0_rx_ch_0 - 00_1006_4830 dma_cur_daddr_mac_0_tx_ch_0 - 00_1006_4c30 dma_cur_daddr_mac_0_rx_ch_1 - 00_1006_4930 dma_cur_daddr_mac_0_tx_ch_1 - 00_1006_4d30 dma_cur_daddr_mac_1_rx_ch_0 - 00_1006_5830 dma_cur_daddr_mac_1_tx_ch_0 - 00_1006_5c30 dma_cur_daddr_mac_1_rx_ch_1 - 00_1006_5930 dma_cur_daddr_mac_1_tx_ch_1 - 00_1006_5d30 dma_cur_daddr_mac_2_rx_ch_0 - 00_1006_6830 dma_cur_daddr_mac_2_tx_ch_0 - 00_1006_6c30 dma_cur_daddr_mac_2_rx_ch_1 - 00_1006_6930 dma_cur_daddr_mac_2_tx_ch_1 - 00_1006_6d30 dma_cur_daddr_ser_0_rx - 00_1006_0430 dma_cur_daddr_ser_0_tx - 00_1006_04b0 dma_cur_daddr_ser_1_rx - 00_1006_0830 dma_cur_daddr_ser_1_tx - 00_1006_08b0 read only bits name default description table 99: ethernet receive packet drop registers (only if system revision >= periph_rev3) dma_oodpktlost_mac_0_rx_ch_0 - 00_1006_4838 dma_oodpktlost_mac_0_rx_ch_1 - 00_1006_4938 dma_oodpktlost_mac_1_rx_ch_0 - 00_1006_5838 dma_oodpktlost_mac_1_rx_ch_1 - 00_1006_5938 dma_oodpktlost_mac_2_rx_ch_0 - 00_1006_6838 dma_oodpktlost_mac_2_rx_ch_1 - 00_1006_6938 bits name default description 15:0 oodlost 16'b0 this is the count of packets that were dropped by the channel because it was out of descriptors when the start of the packet was received. (the count will not be incremented if the channel has descriptors available but is disabled, or if the channel has descriptors but the drop bit is set.) the counter will stick at 16'hffff to indicate 65535 or more packets dropped. 23:16 eop_count 8'b0 this field contains the current value of the counter that controls the completion interrupt. 63:24 reserved 40'bx this field is reserved. reads will return unpredictable data. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 169 e thernet and s erial dma d escriptors table 100: dma descriptor first doubleword dscr_a bits name description 4:0 offset the offset in the buffer that the header should start at. 39:5 a_addr the base address of the data buffer (cache block aligned). in ring mode this is the base address of the first data buffer. 48:40 a_size the size of the data buffer (in cache blocks). if this field is zero the buffer is 512 cache blocks. in a transmit channel which has the tbx_en configuration bit set bit [40] must be zero. 49 interrupt if this bit is set an interrupt will be raised when the dma engine has finished using this descriptor. 50 offset_b if this bit is set then the offset field will be applied to the first buffer pointed to by descriptor b in a packet rather than the first buffer pointed to by descriptor a. the dma controller behavior is unpredictable if this bit is set in chain mode. if this bit is set, the b_valid bit must be set in the decr_b or the behavior od the dma engine will be unpredictable. 63:51 status in the first descriptor of a received packet this field will be updated with the packet status at the end of reception. the flags differ between the interfaces and are described in section: ?option and flag bits for ethernet macs? on page 171 and section: ?control and flag bits for synchronous serial interface? on page 174 . table 101: dma descriptor second doubleword dscr_b bits name description 3:0 options this field sets the per packet options that are sent to the interface. the options depend on the channel, and are outlined below. 4 addr in chain mode this bit provides the additional address bit that is used with bits 39:5 to form the pointer to the next descriptor. in ring mode the bit is reserved and should be zero. 39:5 b_addr in ring mode this gives the base address of the second data buffer (cache block aligned). in chain mode it and bit 4 contain a pointer to the next descriptor. 48:40 b_size the size of the second data buffer (in cache blocks). if this field is zero the buffer is 512 cache blocks. in a transmit channel which has the tbx_en configuration bit set bit [40] must be zero. 49 b_valid if this bit is set the buffer is valid and will be used. if this bit is clear the b buffer is not used and the b_addr and b_size fields are ignored. (ring mode only.) 63:50 pkt_size in the first descriptor of a packet this field contains the packet length. in a transmit channel the length is written by the cpu as part of setting up the descriptor and is passed to the interface. in a receive channel the length is written back into the descriptor at the end of reception. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 170 section 7: dma document 1250_1125-um100-r table 102: unaligned buffer form at dma descriptor first doubleword dscr_a bits name description 39:0 addr the base address of the data buffer. 47:40 unused unused. if extra_status is enabled the receive dma engine will overwrite this field. 48 reserved reserved. 49 interrupt if this bit is set an interrupt will be raised when the dma engine has finished using this descriptor. 50 reserved reserved. 63:51 status in the first descriptor of a received packet this field will be updated with the packet status at the end of reception. the flags are described in section: ?option and flag bits for ethernet macs? on page 171 . table 103: unaligned buffer format dma descriptor second doubleword dscr_b bits name description 3:0 options this field sets the per packet options that are sent to the interface. the options depend on the channel, and are outlined below. 7:4 reserved reserved. 21:8 size this field specifies the buffer size in bytes. this field must be set to the number of bytes of data in the buffer plus bits [4:0] of the start address in the dscr_a addr field. the dma engine behavior is unpredictable if this size is set to be less than the value of bits [4:0] of the address in dscr_a. 47:22 reserved reserved. 49:48 pkt_size_msb this field provides bits [15:14] of the packet size. (note that if packets greater than 16k-1 are used only the low 14 bits of the length is added to the rmon counters.) 63:50 pkt_size in the first descriptor of a packet this field contains the packet length. in a transmit channel the length is written by the cpu as part of setting up the descriptor and is passed to the interface. in a receive channel the length is written back into the descriptor at the end of reception. in unaligned buffer mode this field is extended to 16 bits using the pkt_size_msb field as the upper two bits. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 171 o ption and f lag b its for e thernet mac s table 104: status flags for ethernet receive channel bits name description flags written to dscr_a size_a field if extra_status is enabled 47:40 dscr_cnt number of descriptors used by this packet. if more than 255 descriptors were used to receive the packet then this field will be 0 and software must compute the actual number. this field is valid for ethernet and packet fifo modes. 48 reserved this bit may be used for status information in the future. flags written to dscr_a options field 51 bad_ip4cs this bit is clear if at the offset specified in the iphdr_offset field of the mac_adfilter_cfg register the receive packet has a standard length (no options) ipv4 header with a valid header checksum. otherwise it is set. this flag is only valid in ethernet mode. 52 dscr_err descriptor error. during packet reception the channel ran out of descriptors, the tail of the packet is lost. when this bit is set, the length field can be used to determine the number of bytes transferred before the receiver ran out of descriptors. if the system_revision indicates periph_rev3 or later, the length field indicates the number of bytes transferred. in older revisions the field must be corrected to account for the offset at the start of the packet. software should compensate by subtracting the low three bits of the offset field: actualbytestransferred = dscr_b.pkt_size - 32 - (dscr_a.offset & 7) this flag is valid for ethernet and packet fifo modes. 54:53 rx_ch receive channel number (always 2?b00 for dma channel zero) this field is valid for ethernet and packet fifo modes. 57:55 pkt_type packet type. contains an encoded version of the ethernet type field. see section: ?packet type identification? on page 281 . this field is valid for ethernet and packet fifo modes. (it depends on the packet format so it may not be useful in packet fifo mode.) 58 match_hash this bit is set if the packet passed the hash match filter. this field is valid for ethernet and packet fifo modes. (it depends on the packet format so it may not be useful in packet fifo mode.) 59 match_exact this bit is set if the received packet passed the exact addresses filter. (the packet will pass if it matched an address and the filter was true, or the packet did not match and the filter was inverted). this field is valid for ethernet and packet fifo modes. (it depends on the packet format so it may not be useful in packet fifo mode.) 60 bcast this bit is set if the received packet has a broadcast address. this field is valid for ethernet and packet fifo modes. (it depends on the packet format so it may not be useful in packet fifo mode.) 61 mcast this bit is set if the received packet has a multicast address. this field is valid for ethernet and packet fifo modes. (it depends on the packet format so it may not be useful in packet fifo mode.) 62 bad this bit is set if the received packet has errors (length error or dribble error or code error or crc error or is a runt packet or is an oversize packet). see table 162 on page 275 for a description of the errors. in packet fifo mode, the error bit will be set by a crc error or the packet is terminated with a link error (only possible in gmii style and encoded modes). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 172 section 7: dma document 1250_1125-um100-r 63 sop this bit is set to indicate the start of the packet. software should ensure this bit is clear when it sets up the descriptor, the dma controller will only set it when packet reception has been completed. flags written to dscr_b options field 0 bad_tcpcs the value of this bit is only valid if the interface is in ethernet mode and the bad_ip4cs bit is clear. when valid, this bit is clear if the packet received has a correct tcp checksum, and set if the packet has a bad tcp checksum. since udp uses the same checksum algorithm this flag also applies to udp packets. 1 vlan_flag this bit is only valid if the system revision indicates periph_rev3 or greater and for ethernet operation and the vlan_det_en bit is set in the mac_adfilter_cfg register. this bit will be set when a packet with a vlan tag is received and clear if there is no vlan tag. 2 crc_flag this bit is only valid if the system revision indicates periph_rev3 or greater. ethernet mode only: this flag is set (in addition to the bad bit) when a crc error is detected. 3 reserved this bit may be used for status information in the future. table 104: status flags for ethernet receive channel (cont.) bits name description table 105: option flags for ethernet receive channel receive options bits name description none table 106: status flags for ethernet transmit channel transmit status flags bits name description 62:51 ignored preserved when the descriptor is written. 63 sop this bit must be set for the first descriptor in a packet. the dma engine will report a descriptor error if it is starting a new packet and this bit is clear in the corresponding descriptor. this bit is cleared when the descriptor is written. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 173 table 107: option flags for ethernet transmit channel transmit commands bits name description 3:0 pkt_mod this field indicates how the transmitter should modify the packet. 0000: descriptor is not start of packet. 0001: append crc. 0010: replace crc. 0011: append crc and pad. 0100: append vlan tag and replace crc. 0101: remove vlan tag and replace crc. 0110: replace vlan tag and replace crc. 0111: no modifications. 1000: reserved 1001: replace source address and append crc. 1010: replace source address and replace crc. 1011: replace source address, append crc and pad. 1100: replace source address, append vlan tag and replace crc. 1101: replace source address, remove vlan tag and replace crc. 1110: replace source address, replace vlan tag and replace crc. 1111: reserved descriptors with the sop bit set in their transmit status flags must have a nonzero value in this field. if the sop bit is clear this field must be zero. in packet fifo modes all codes are reserved except for: 0000: descriptor is not start of packet. 0001: append crc. 0111: no modifications. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 174 section 7: dma document 1250_1125-um100-r c ontrol and f lag b its for s ynchronous s erial i nterface table 108: status flags for synchronous serial receive channel receive status flags bits name description 55:51 reserved reserved 56 crc_error this bit is set if the received packet has a bad crc. 57 abort this bit is set if the received packet ended with the abort flag. 58 octet_error this bit is set if the size of the received packet was not a multiple of 8 bits. 59 longframe_error this bit is set if the size of the received packet is bigger than the maximum frame size. 60 shortframe_error this bit is set if the size of the received packet is shorter than the minimum frame size. 61 overun_error this bit is set if the received packet over ran the fifo and is therefore invalid. 62 good this bit is set if the received packet has no errors. 63 sop this bit is set to indicate the start of the packet. software should ensure this bit is clear when it sets up the descriptor, the dma controller will only set it when packet reception has been completed. table 109: option flags for synchronous serial receive channel receive options bits name description none table 110: status flags for synchronous serial transmit channel transmit status flags bits name description 62:51 ignored preserved when the descriptor is written. 63 flag this bit is cleared when the descriptor is written. software can set this bit in descriptors associated with the start of a packet and the bit will be cleared when the packet has been transmitted. (unlike the ethernet there is no requirement that this bit be set for a sop). table 111: option flags for synchronous serial transmit channel transmit commands bits name description 0 reserved reserved 1 append crc if this bit is set the computed crc will be appended to the packet. 2 append pad if this bit is set the packet will be padded to the minimum packet size. 3 abort if this bit is set the packet will be ended with an abort instead of a standard flag. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 175 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 176 section 7: dma document 1250_1125-um100-r d ata m over the data mover can perform transfers between arbitrary addresses. the source for a transfer can be either memory or an i/o device, and the destination of the transfer can be either memory or an i/o device. the alignment of the source and destination can differ, in which case the engine will participate in the mesi coherence protocol to ensure the correct merge is done at the start and end of the transfer. the data mover has four channels (in many cases this is sufficient for them to be allocated to processors/processes to avoid the need for locking accesses to the control registers). when multiple channels have requests a modified round robin service schedule is applied, this provides fair access to all the channels while optimizing requests to memory to allow open-bank page mode access. the buffering in the data mover is sufficient that it can run at the full memory bandwidth. d ata m over o peration the data mover channels can only be configured for ring mode. the descriptor a pointer points to the destination of the transfer and the descriptor b pointe r points to the source of the transfer. these addresses can have any alignment. there is no buffer size, just the length parameter which may specify up to 1 mbyte of data. the data mover reads and writes in 32 byte blocks as much as possible, either using the full coherence protocol or as uncached but merged data (similar to the cpu uncached accelerated). if the full coherence protocol is used and a smaller block needs to be written the data mover will read the block exclusive, merge in the new data and write the block back. if uncached accelerated mode is used then the byte enable signals will indicate the valid data and the data mover does not do a merge. the source and destination addresses can be incremented, decremented or held constant for each 32 byte block. this allows movement of overlapping regions; if the source address is less than the destination the data should be moved from the top end of the buffer with both addresses decrementing, if the source address is greater then the data should be moved starting at the bottom of the region and incrementing the addresses. holding the address constant is useful for transfers to or from i/o devices. if the source and destination move in different directions the data mover will not reorder the bytes within the 32 byte line, and the addresses must be cache aligned. in this case if a[4:0] of either address is nonzero the behavior of the move is unpredictable. there is a level 2 cache flag associated with both the source and destination addresses. this is used to request the data be allocated in the l2 cache on a miss. in most cases it would only be used on the destination side (if at all) since there is little point in caching data that is being moved. one case where the l2 cacheability attribute would be set on the source is when the prefetch bit is set. in this case the destination is ignored and only the reads are done. if the reads are done with the l2 allocation bit set this will prefetch the data into the l2 cache. in uncacheable i/o space this mode could be used to flush an external fifo. there is also a zero_mem bit. if this is set the source address is ignored and destination is written with zeros. if the data mover is used to perform accesses to the hypertransport space it can only use a subset of reads. for any access the hypertransport interface will only accept reads that are less than 8 bytes or are aligned to a 4 byte boundary and a multiple of 4 bytes (up to the full 32 bytes in the block), any other sizes will result in undefined behavior. thus a move may need to be broken up into the odd bytes needed to align to a 4 byte boundary, then the main block (a multiple of 4 bytes), then the tail bytes. any size of write will work correctly. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 177 channels of the data mover can be individually enabled and reset. the reset bit should only be written when the channel is currently disabled or being disabled (i.e. it can be written with either the enable or disable command). the act of writing the reset bit causes the current descriptor pointer to be reset to the ring base address. note that the reset bit for a channel should always be set to initialize the channel when it is enabled for the first time. there are two ways to disable a channel. the first is to clear the enable bit, which causes the engine to complete the transfer that is in progress and stop until re-enabled when it will continue with the next descriptor (unless reset). the second method is to set the abort bit in the same write that clears the enable bit, this causes the current transfer to be abandoned and the engine stops immediately. when re-enabled after being aborted the data mover will start with the next descriptor, so the end of the transfer that was aborted will be lost. the active status bit indicates that the channel is currently in use. if the enable bit is cleared the active bit will remain set until the channel is has finished any transfer and is disabled. the round robin weights are only used when more than one channel is busy. the data mover will service requests from a channel until it has completed the number of transfers in the weight parameter for that channel or there are no descriptors queued. the next channel is then serviced. note that the weights are by transfer, not by number of bytes transferred. to achieve true bandwidth sharing the transfer sizes need to be similar (as do the latencies for the reads and writes). if it is important for system behavior to have a better sharing of the data mover, software should break down large transfers into a series of smaller transfers to enable finer granularity on the round robin. the data mover descriptors include an interrupt bit. if this is set then when the transfer specified in the descriptor is complete the interrupt bit will be set in the dm_dscr_base register and the channel interrupt will be raised. if an error is flagged on any data read (either for descriptors or for data blocks) the error bit will be set, the channel interrupt raised and channel will abort and disable. both the error and interrupt bits are cleared by reads to the dm_dscr_base register, clearing the interrupt. a high load can be put on the system by the data mover. as soon as the data returns for one of its four outstanding reads it will write the data and issue another read. to prevent this, data transfers can be throttled on either the read or the write (or both), this is a parameter of the transfer set in the descriptor. when enabled the data mover will check the blocking signal from the agent and will only request if the blocker has been clear for the previous four zbbus cycles. to avoid starvation there is a timeout, if the data mover is forced to backoff 16 times (e.g. the blocker deasserts but some other agent inserts a request causing the block to assert in less than four cycles) it will request the next time the blocker is clear. in parts with system revision indicating periph_rev3 or greater the data mover will prefetch descriptors by overlapping the descriptor fetch with the data transfer of the previous transaction. this improves performance if small transactions are used. a side effect of this is that the current descriptor and count may be one ahead of the transfer in progress (although the count will not go to zero until the channel is idle). if the channel is disabled a prefetched transaction may be completed before the channel goes inactive. an abort will stop the channel immediately and it is unpredictable if it stops during the original or prefetched transaction. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 178 section 7: dma document 1250_1125-um100-r crc and c hecksum g enerators in parts with system revision indicating periph_rev3 or greater the data mover includes a programmable crc generator and a checksum engine that computes the ones-complement checksum used by the tcp and udp protocols. these can be used as part of a data copy or with the prefetch (null destination) parameter to read the data and generate the result without a copy. each of the four channels has its own register to store the current state information for the crc and checksum in progress in that channel, allowing the channels to be operated independently and with arbitrary interleave. the crc and checksum operations are only supported when the addresses increment, the results of enabling crc or checksum with a decrementing source or destination address are undefined. the basic operation is the same for both crc and checksum. the generator is controlled by the data mover descriptors and a single crc or checksum computation may be split over multiple descriptors (there can even be unrelated moves that do not use the generators mixed in). for both generators each descriptor includes an enable flag, a reset flag and an append flag. if the enable flag is set then the function is enabled for this move. when the engine is enabled if the reset flag is set then the partial result is set to the initial value before the move is started and if the append flag is set the final result is written to the destination address after the move has completed. in all cases the software readable partial result register is updated at the end of the move. the partial result register may be saved by software if a computation is interrupted and can be written to restore the result before the computation is resumed (this requires control of the dma channel and in many cases can be avoided since a different computation can be performed in other channels). the data in the partial result register is only valid when the channel is not currently computing a checksum or crc, and the register should only be written when the channel is not computing. if the data mover channel is disabled then the crc and checksum partial result registers will contain valid data when the active bit becomes clear, and the computation may be resumed when the channel is enabled again. if the channel is aborted then the partial result registers and the results of any in-progress generation become unpredictable and it is not possible to resume the computation. checksum generation if the checksum is enabled then for every 16 bits in the move the data is added to the partial sum using the tcp/udp ones-complement maths. the value that the sum should be initialized to at the start of a computation must be set in the tcpcs_init field, in most cases this will be zero. at the start of moves that have the reset flag set the current sum is set from this initial value. at the start of any move with the checksum enabled that does not have the reset flag set the current sum is updated from the partial sum register for that channel. at the end of any move that has the checksum enabled the partial sum register associated with a channel is updated. if there is a byte left over and the append bit is set then the final byte and a byte of zeros is added to the partial sum before the result is appended. if there is a byte left over and the append bit is not set then the byte is included in the sum and a flag set to ensure the first byte of the next description is used to complete the 16-bit sum. when the sum is appended it behaves just as if the move were two bytes longer, and any partial cache line is merged with a read-modify-write cycle if cacheable. if the prefetch bit is set then no regular data is moved and just the checksum is written to the destination (again with a read-modify-write merge if required). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 179 note that if the prefetch flag is set no data will be moved and the destination address is used just to write the tcp sum if the append flag is set. if the prefetch flag is clear then data will be moved as the checksum calculation is done and the tcp sum is appended if the append flag is set. if the zero_mem flag is set then zeros are added to the sum, this has no effect unless there is a retained byte from a previous merge to combine in to the sum. if the prefetch and zero_mem flags are both set no memory is zeroed but zeros will be added to the sum, again this will have no effect unless there is a retained byte or a retained byte is created. crc generation the programmable crc generator can be used to generate any crc up to 32 bits (output fieldwidths of 8, 16 and 32 bits are supported). there are two sets of crc definition registers and each datamove specifies which should be used. the crc is programmed using a set of parameters: crc_init 32 bit initial value crc_poly 32 bit polynomial crc_width sets width of output crc field (32, 16 or 8 bit) crc_txor 32 bit value to xor the final crc crc_bit_order sets the order of bits within a byte for the computation (0 for bit 0-7, 1 for 7-0) when the crc width is less than 32 bits the definition should be put in the high end of the registers. thus for a 16 bit crc the width is set to 16, the polynomial must be placed the upper half of the crc_poly field (i.e. bits 63:48 of the crc_def register), the initial value will come from the upper half of the crc_init field (i.e. bits 31:16 of the crc_def register) and the partial result will be in the upper bits (31:16) of the crc_partial register. for an 8 bit crc the width is set to 8 the polynomial must be placed in the upper byte (63:48) of the crc_poly field, the initial value will come from the upper byte (31:24) of the crc_init field and the partial result will be in the upper byte (31:24) of the crc_partial register. for other crc widths the next larger output field width should be used and the crc result will be in the upper bits of the field and the upper bits of the registers are used for the definition. in all cases unused bits must be set to zero or the result will be unpredictable. before the result is written to memory it is xored with the crc_txor value. many crcs require this to prevent all zero data having a zero crc. the polynomial arithmetic behind the crc algorithms splits a message (and the attached crc) into the coefficients of a polynomial. this is normally done in the order the bits flow serially over the wire. while all interfaces send bytes in the order of ascending memory address, some choose to send the least significant bit of the byte first and some the most significant bit first. this changes the order of the bits needed for the crc computation. the generator can compute with either order as set by the crc_bit_order flag. there is a similar issue when the crc result is written to memory. the data is always written in big endian manner (i.e. the high bits of the result get written to the lower memory addresses) to match the final packet being sent in the order of ascending memory address. but again a swap may be needed within the bits. this final swap is specified in the dma descriptor by setting the crc_xbit flag. this should only be done in the last descriptor of the computation. table 112: result in memory of appending the result crc[31:0] addr+0 addr+1 addr+2 addr+3 crc_xbit = 0. big endian order crc[31:24] crc[23:16] crc[15:8] crc[7:0] crc_xbit = 1. big endian order, bit swapped bytes crc[24:31] crc[16:23] crc[8:15] crc[0:7] bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 180 section 7: dma document 1250_1125-um100-r table 113 gives some example values for some common crcs (in a particular use care will need to be taken with the final bit order). if the crc is enabled then for every byte in the move the data is merged in to the partial crc. at the end of any move that has crc enabled the partial sum register associated with a channel is updated. at the start of any move with crc enabled that do not have the reset flag set the current sum is updated from the partial sum register for that channel. at the start of any move that has the reset flag set the current sum is set to the crc_init value for the selected crc definition. at the end of a move that has the append bit or the crc_xbit flag set the partial sum register associated with the channel is written with the final crc value after the xor and bit-flip have been done. if the append bit is set then the crc is appended before the checksum and is included in the checksum. this matches protocols such as iscsi where the crc is internal to the tcp payload. the number of bytes appended will be 1, 2 or 4 to match the field width of the crc. if required a read-modify-write is done. note that when a checksum is appended it is not included in the crc. when the prefetch flag is set no data will be moved and the destination address is used just to write the crc if the append flag is set. if the prefetch flag is clear then data will be moved as the crc calculation is done and the crc is appended if the append flag is set. if the zero_mem flag is set then zeros are added to the crc, this will have an effect on the result. if both prefetch and zero_mem flags are set then the zeros will be added to the crc but no memory will be zeroed. computation sizes and bandwidth the tcp checksum is done in 16-bit operations, and crc calculation is done in 12-bit operations so for a full 32 byte cache line 16 or 24 zbbus cycles are needed. there will be a few clocks overhead, but this gives a theoretical max sum/crc bandwidth of about 6 or 4 gbps. table 113: example crc configurations crc_width crc_poly crc_init crc_txor crc_bit_order crc_xbit crc32 (ethernet) 32 04c11db7 ffffffff ffffffff 11 crc32c (iscsi) 32 1edc6f41 ffffffff ffffffff 11 crc-ccitt (hdlc) 16 80050000 00000000 00000000 11 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 181 examples the following examples illustrate uses of the checksum and crc engine. these are intended to illustrate use of the data mover generators, in some cases it will be more efficient to do more processing of small buffers on the cpu rather than expending more effort on managing descriptors. figure 33: example 1 - tcp checksum a packet example 1 illustrated in figure 33 shows preparing a packet for transmission by computing its tcp checksum. the example has a packet made up of a header buffer (with ethernet, ip and tcp headers) and two data buffers. prior to passing the descriptors to the data mover software should compute the checksum of the pseudo-header (the source and destination ip addresses, the protocol type and the tcp length) and write this (rather than zero) to the checksum field in the tcp header. the descriptors are set up so the first resets the sum and adds the bytes in the tcp header. the pseudo-header sum is included (this takes advantage of the fact that the order of the adds does not matter). the second descriptor adds the first data block, and the third descriptor the second data block. because the prefetch flag is set the buffers are only read and no copy is made. the third descriptor has the append cs flag set so the destination address is used to write out the final checksum. the destination points to the checksum field in the tcp header, so the final checksum is automatically written into the packet. if the packet is going to be sent over the ethernet interface after only a short delay then consideration should be given to setting the l2ca_src flag in all the descriptors so the packets are only read from memory once and staged in the l2 cache for transmission. in this example l2ca_src should certainly be set in the first descriptor since the buffer will be at most two cache blocks and the data mover will soon be doing a read-modify-write to update the two checksum bytes. eth data (1) src enable cs hdr ip hdr tcp hdr data (2) dst reset cs prefetch src enable cs dst prefetch src enable cs dst append cs prefetch len=tcphdr len=len(1) len=len(2) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 182 section 7: dma document 1250_1125-um100-r example 2 illustrated in figure 34 shows preparing an iscsi packet for transmission. the example has a packet made up of a single buffer, although split buffers could also be used. again, software must compute the pseudo-header sum and put it in the tcp header checksum field. the first descriptor initializes the tcp checksum and computes the crc of the iscsi header information, when this is inserted into the packet it will be included in the tcp checksum. the second descriptor causes the crc of the data to be computed and inserted. in this case the tcp checksum is just continued. the third move adds the tcp header (and pseudo- header sum) to the checksum and stores the result in the tcp checksum field. (in practice it may be more effective to just use descriptors 1 and 2 and have the checksum appended after the packet by descriptor 2. the software can then collect the checksum and do the pseudo-header and tcp header computation.) figure 34: example 2 - preparing an iscsi packet example 2 can be extended into a more extreme form to also have the data mover schedule the packet for transmission. assume all iscsi packets get processed through one channel of the data mover and they are the only packets added to one transmit channel of a mac. if the cpu prepares a mac dma descriptor at the same time as the data mover descriptors and places the mac descriptor in the mac dma ring (without incrementing the count) then an additional data move could do a single doubleword copy of the value 1 to the mac dma descriptor count register (using an uncached destination to ensure only one doubleword is written). this is a somewhat inefficient use of the data mover but has offloaded the cpu from fielding the datamover interrupt and writing the mac register. example 3 illustrated in figure 35 on page 183 shows preparing a large iscsi block for fragmentation before transmission. the example has a packet made up of a single buffer, although split buffers could also be used. the data mover is used to compute the iscsi crcs and the partial tcp checksums that cover the data in each fragment. the crcs are inserted into the data block, the checksums are written to a separate array. the first descriptor resets the checksum for the first fragment and computes and inserts the iscsi header crc, the appended crc will be included in the tcp sum. the second descriptor resets the crc for the data computation, but keeps the checksum running. at the end of the first fragment the tcp checksum is written into the array (the appended checksum is not included in the crc so this does not disturb the running crc). descriptor 3 covers the second fragment which needs its own checksum, but continues the crc (if there were more fragments this style of descriptor could be repeated). the fourth descriptor covers the final fragment and will append the datablock crc and include this crc in the final checksum. there is then a problem because eth iscsi data src enable cs hdr ip hdr tcp hdr dst reset cs prefetch src dst prefetch src enable cs dst append cs prefetch len=iscsihdr len=len(data) len=tcphdr iscsi hdr idata crc ihdr crc enable crc reset crc enable cs enable crc reset crc append crc append crc user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 183 if the checksum were appended in this descriptor it would be put on the end of the buffer after the crc (software could do this and pick the final checksum from there). in the example this is solved using the observation that adding zeros does not change the checksum. in the example a final descriptor is used to add 2 zeros to the checksum (i.e. a 16-bit halfword of zero) and place the final checksum into the array. the software can combine the partial checksums from the array with the header checksums when it computes the headers prior to transmitting the packets. this example could be modified to a more extreme form in a similar manner to example 2: if the header buffers were prepared by software before the data mover were started then rather than having the tcp checksums written to an array the append cs would be removed from the second and third descriptors, and additional descriptors inserted after the second and third and to replace the final one. these descriptors would have the crc disabled and would add and append the tcp sum in the same way as the third descriptor in example 2. with appropriate setup of the mac dma ring moving a single doubleword to the mac dma count register would allow the packets to be scheduled for transmission. figure 35: example 3 - fragmenting an iscsi packet iscsi data src enable cs dst reset cs prefetch src dst prefetch src enable cs dst append cs prefetch len=iscsihdr len=frag1- len=frag2 iscsi hdr idata crc ihdr crc enable crc reset crc enable cs enable crc reset crc append crc append cs reset cs enable crc enable cs append crc prefetch reset cs enable crc src dst len=frag3 append cs prefetch enable cs zero src dst len=2 iscsihdr partial tcp checksum array bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 184 section 7: dma document 1250_1125-um100-r d ata m over c ontrol r egisters table 114: data mover descriptor base address register dm_dscr_base_0 - 00_1002_0b00 dm_dscr_base_1 - 00_1002_0b20 dm_dscr_base_2 - 00_1002_0b40 dm_dscr_base_3 - 00_1002_0b60 read clears some bits bits name default description 3:0 zero 4'b0 these bits must be zero. 39:4 base 36'bx this is the base address of the descriptor ring. 55:40 ring_size 16'bx this field sets the total number of descriptors in the ring. if this field is set to 0 the ring will contain 65536 descriptors. 58:56 priority 3'bx this field gives the weight for this channel. it sets how many descriptors are processed from this channel before advancing round robin to the next channel. 000: 1 descriptor. 001: 2 descriptors. 010: 4 descriptors. 011: 8 descriptors. 100: 16 descriptors. 101-111: reserved 59 active 1'b0 read only. this bit is set when a descriptor from the current channel is actively being used. when the enbl bit is cleared the channel will remain enabled until this bit is clear. 60 interrupt 1'b0 read only. this bit is set when the channel is interrupting because of the end of a transfer with the descriptor interrupt bit set. this bit is cleared by a read from the dm_dscr_base register. 61 error (r/o) reset (w/o) 1'b0 on a read this bit is set when the channel is interrupting because of a data transfer error (uncorrectable ecc, bus error or fatal bus error signalled on the d_code). if such an error occurs the channel will abort. this bit is cleared by a read from the dm_dscr_base register. if this bit is written with a 1 the current descriptor pointer is reset to the base address of the descriptor ring (bits 39:0). this should always be done the first time a channel is enabled. 62 abort(w/o) 1'b0 if this bit is written with a 1 the dma engine will abort the current transfer and disable the channel. if both this bit and the enbl bit (bit 63) are set in the same write, this bit will override and the channel will be aborted. 63 enbl 1'b0 this bit must be set to enable the dma channel. if this bit is cleared while the channel is running the current transfer is completed before the engine stops. (use the abort bit to cause the engine to stop immediately). table 115: debug data mover descriptor base address register dm_debug_dscr_base_0 - 00_1002_0b18 dm_debug_dscr_base_1 - 00_1002_0b38 dm_debug_dscr_base_2 - 00_1002_0b58 dm_debug_dscr_base_3 - 00_1002_0b78 read only bits name description 63:0 dscr_base reading from this register gives the same data as reading from the dm_dscr_base register ( ta b l e 11 4 ), but without the side effect of clearing the interrupt and error status bits. it is intended for debugger access to the status. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 185 table 116: data mover descriptor count register dm_dscr_count_0 - 00_1002_0b08 dm_dscr_count_1 - 00_1002_0b28 dm_dscr_count_2 - 00_1002_0b48 dm_dscr_count_3 - 00_1002_0b68 bits name default description 15:0 count 16'b0 this is the number of descriptors owned by the dma engine. reads will return the number of unused descriptors. data that is written to this register will be added to the count (assigning that number of additional descriptors to the controller). 63:16 reserved 48?b0 reserved table 117: data mover current descriptor address dm_cur_dscr_addr_0 - 00_1002_0b10 dm_cur_dscr_addr_1 - 00_1002_0b30 dm_cur_dscr_addr_2 - 00_1002_0b50 dm_cur_dscr_addr_3 - 00_1002_0b70 read only bits name default description 39:0 dscr_addr 40'bx the current descriptor address can be read from this field. 47:40 reserved 8'b0 reserved 63:48 cur_count 16'b0 the current count of descriptors owned by the dma engine can be read from this field. table 118: data mover crc definition registers (only if system revision >= periph_rev3) crc_def_0 - 00_1002_0b80 crc_def_1 - 00_1002_0b90 bits name default description 31:0 crc_init 32'bx this is the initial value for the partial crc and is loaded into the partial result register before a move that has the crc_reset flag set. for crcs smaller than 32 bits the initial value should be put into the high bits of this field and the low bits should be zeros. 63:32 crc_poly 32'bx this is the polynomial used to define the crc. for crcs smaller than 32 bits the polynomial value should be put into the high bits of this field and the low bits should be zeros. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 186 section 7: dma document 1250_1125-um100-r table 119: data mover crc/checksum definition registers (only if system revision >= periph_rev3) ctcp_def_0 - 00_1002_0b88 ctcp_def_1 - 00_1002_0b98 bits name default description 31:0 crc_txor 32'bx this value is xored with the partial result of the crc computation before the final result is written to memory. for crcs smaller than 32 bits the value should be put into the high bits of this field and the low bits should be zeros. 47:32 tcpcs_init 16'bx this is the initial value for the checksum and is loaded into the partial result register before a move that has the tcpcs_reset flag set. 49:48 crc_width 2'bx this sets the field width used when the crc is written to memory: 00 - 4 bytes (32 bits) 01 - 2 bytes (16 bits) 10 - 1 byte (8 bits) 11 - reserved 50 crc_bit_order 1'bx this selects the bit order used when the crc engine is reading bytes. 0 - bit 0 is used first and bit 7 last 1 - bit 7 is used first and bit 0 last 63:51 reserved 13'bx reserved. table 120: data mover channel partial result re gisters (only if system revision >= periph_rev3) dm_partial_0 - 00_1002_0ba0 dm_partial_1 - 00_1002_0ba8 dm_partial_2 - 00_1002_0bb0 dm_partial_3 - 00_1002_0bb8 bits name default description 31:0 crc_partial 32'bx current partial crc result. after a transfer with the crc_ap append bit set this register will contain the final crc result (after xor and bit-flip). for crcs smaller than 32 bits the value is in the high bits of this field. if the value is saved it may be written back later to allow the crc computation to resume. 47:32 tcpcs_partial 16'bx current checksum partial result. if the value of this field and the odd_byte bit are saved they may be written back later to allow the checksum computation to resume. 48 odd_byte 1'bx this bit is set when the current checksum finished on an odd byte boundary. since the checksum is calculated in 16 bit halfwords this bit being set indicates that the first byte of the next buffer must be added to the low half of the partial result before 16 bit additions are used. if the value of this bit and the tcpcs_partial field are saved they may be written back later to allow the checksum computation to resume. 63:49 reserved 15'bx reserved. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 187 d ata m over d escriptors table 121: data mover descriptor first doubleword dm_dscr_a bits name description 39:0 dst_addr the destination address of the transfer (may be any alignment). 40 un_dest this bit should be set for an uncached destination, and clear if the destination is cacheable coherent. uncached accelerated operations will be used. 41 un_src this bit should be set for an uncached source, and clear if the source is cacheable coherent. uncached accelerated operations will be used. 42 interrupt if this bit is set an interrupt will be generated at the end of the transfer. 43 reserved reserved 45:44 dir_dest this indicates the direction the destination address should be moved: 00: the address is incremented 01: the address is decremented 10: the address is held constant 11: reserved 47:46 dir_src this indicates the direction the source address should be moved: 00: the address is incremented. 01: the address is decremented. 10: the address is held constant. 11: reserved 48 zero_mem if this bit is set the source parameters will be ignored, and zeros will be transferred to the destination address. 49 prefetch if this bit is set the destination parameters will be ignored, the data will just be read from the source. this can be used with the l2c_src bit to prefetch lines from memory into the l2 cache. note: when used in this manner, it is most efficient if the src address is 32 byte aligned. 50 l2c_dest if this bit is set writes to the destination buffer are marked l2_cacheable and will therefore be allocated in the l2 on an l2 miss. (for cacheable transfers the l2 is always checked, and will always be updated if hit). 51 l2c_src if this bit is set reads from the source buffer are marked l2_cacheable and will therefore be allocated in the l2 on an l2 miss. (for cacheable transfers the l2 is always checked, and will supply the data if hit). 52 rd_bkoff if this bit is set the data mover will backoff from a read transfer until the destination blocker has been clear for four zbbus cycles. 53 wr_bkoff if this bit is set the data mover will backoff from a write transfer until the destination blocker has been clear for four zbbus cycles. 54 tcpcs_en set to enable tcp checksum (system revision periph_rev3 or greater) 55 tcpcs_res set to reset tcp partial sum to init valu e at start of move (system revision periph_rev3 or greater) 56 tcpcs_ap set to append tcp checksum at end of move (system revision periph_rev3 or greater) 57 crc_en set to enable crc engine (system revision periph_rev3 or greater) 58 crc_res set to reset partial crc to init value at start of move (system revision periph_rev3 or greater) 59 crc_ap set to append crc at end of move, but before checksum (system revision periph_rev3 or greater) 60 crc_dfn selects which tcp/crc definition to use (system revision periph_rev3 or greater) 61 crc_xbit set to swap the bits within the crc bytes prior to checksumming and appending to the packet and/or updating the partial register. typically only set for last block of crc (if the crc needs the bitflip). (system revision periph_rev3 or greater) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 188 section 7: dma document 1250_1125-um100-r 63:62 reserved reserved table 122: data mover descriptor second doubleword dm_dscr_b bits name description 39:0 src_addr the source address of the transfer (may be any alignment). 59:40 length the length of the transfer in bytes. if this field is zero then 2^20 bytes will be transferred. 63:60 reserved reserved table 121: data mover descriptor first doubleword (cont.) dm_dscr_a bits name description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 7: dma page 189 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 190 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r section 8: pci bus and hypertransport fabric i ntroduction the pci bus and hypertransport (formerly called ?lightning data transport? or ?ldt?) fabric provide the main general expansion buses for the bcm1250 and BCM1125/h parts. pci is the standard bus used for peripheral connection in many systems and there are a wide vari ety of peripheral devices that connect to it. hypertransport (ht) is a high performance replacement for pci on system boards, it uses a chain of unidirectional point to point links to form a fabric of devices running at much higher data rate. the hypertransport devices use the standard pci configuration process, so devices can be migrated from the pci to hypertransport with few software changes. initial devices available for the hypertransport fabric include bridges to pci, pci-x and agp. the bcm1250 and BCM1125h have both ht and pci interfaces, the BCM1125 has only pci. the pci interface conforms to revision 2.2 of the pci standard. it is a 32 bit wide interface, can run up to 66mhz and uses 3.3v signal levels (the interface is not 5v tolerant). pci special cycles, dual address cycles and the lock protocol are not supported. the interface can act as either the host bridge or as a device configured and controlled by another host. these are referred to as host mode and device mode. when operating in host mode an internal arbiter can be used, providing support for four external pci devices; alternatively an external arbiter can be used to allow more external devices. the hypertransport interface conforms to revision 1.03 of the hypertransport specification although to ensure software backwards compatibility with the earlier implementation (based on 0.17 of the ht specification) there are a few differences, mainly in the mechanisms for error reporting (this was not specified in the earlier version of the standard). the hypertransport transmit and receive clocks are usually the same frequency (the receive link frequency may be lower than the transmit frequency), generated from the 100 mhz reference clock. the hypertransport transmit clock can be the reference clock x2, x3, x4, x5 or x6. the interface runs 8 bits wide in each direction, with data sent on both edges of the clock. the hypertransport interface runs as a host bridge, and therefore is always on one end of the hypertransport fabric. support is provided for fabrics with host bridges at each end. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 191 figure 36 shows the physical and logical organization of the pci and hypertransport interfaces. figure 36: pci and hypertransport organization physically the pci and hypertransport interfaces are both connected to zbbus through i/o bridge 0 (as shown on the left in figure 36 ). the i/o bridge implements the zbbus protocol, and includes the address and data buffers for transactions between the zbbus and each interface, the buffers for peer-to-peer transfers between the pci and hypertransport, and the buffer for merging partial cache line writes. the pci and hypertransport interface units implement their respective bus protocols, and include additional data and command buffering. the bandwidths of the connections between the i/o bridge and interface units are sized appropriately for the interfaces, so the hypertransport is not constrained by the pci bandwidths. however, the interfaces are presented logically to the system as if the hypertransport was bridged from the pci bus (shown on the right of figure 36 ). this makes the pci always bus zero to the device enumeration code (this is required by some software) and allows configuration to be based on existing code. zbbus zbbus io bridge 0 pci interface ht interface pci bus ht fabric device a device b device c device d device e device f device e device f pci host bridge ht bridge device a device b device c device d bus 1 physical view logical view bus 0 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 192 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r pci and h yper t ransport a ddress r ange this section describes how devices on the pci bus and hypertransport fabric (and any buses bridged from them) are mapped into the memory space. there are two complexities in the mapping. the first is supporting the different types of access that need to be done, and the second is supporting endian swapping when the part is running as a big endian system (both pci and hypertransport are little endian). a full discussion of the endian issues is in section: ?endian policies? on page 201 , the two endian options match bit lanes and match byte lanes are defined there. all the areas for mapping pci and hypertransport devices, except a hypertransport only expansion area, are put in the low 4 gbytes of the address space so they can be addressed using 32 bits of address in systems that only use 32 bit addressing. accesses to the pci and hypertransport ranges of the address map should be done as uncacheable or cacheable non-coherent. these addresses pass outside the coherence domain of the system. if cacheable coherent accesses are made to the pci or hypertransport space the behavior of the system will become undefined. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 193 the pci and hypertransport portions of the memory map are shown in figure 37 . figure 37: address ranges for cpu access to pci and hypertransport ht device expansion space (40 bit addressing, selectable endian policy) direct mapped to 00_d8_0000 - 00_df00_0000 with match bit lane endian policy pci/ht configuration space (match byte lane) pci i/o devices on pci bus (match byte lane) ?pci i/o? devices on ht fabric (match byte lane) pci i/o devices on pci bus (match byte lane) pci i/o space sent to the southbridge either on pci or ht with compat bit (match byte lane) htinterrupt or eoi cycle direct mapped to 00_4000_0000 - 00_5fff_ffff with match bit lane endian policy pci memory space devices (match byte lane) ht memory space devices with match byte lane endian policy pci memory space devices with match byte lane endian policy n m l k j i h ht special functions (match byte lane) (has fd_2000_0000 added to address) iack read space (match byte lane) run iack cycle to southbridge either on pci or ht with compat bit g f e d c b a f8_0000_0000 80_0000_0000 00_ff00_0000 00_f800_0000 00_df00_0000 00_de00_0000 00_dc00_8000 00_dc00_0000 00_d910_0000 00_d900_0000 00_d800_0000 00_8000_0000 00_6000_0000 00_4000_0000 set by software configuration set by software configuration southbridge/compatibility devices sent either 00_4100_0000 on pci or ht with compat bit (match byte lane) pci full access (match byte lane) pci full access (match bit lane) reserved ff_ffff_ffff fa_0000_0000 f9_0000_0000 o p bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 194 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r m emory m apped d evices there is a 512mb region for mapping memory mapped pci and hypertransport devices. logically this all maps to the pci and a segment of it is bridged to the hypertransport. (on the BCM1125 there is no hypertransport interface and all accesses to this space are pci accesses.) thus the area is divided up into the three regions a, b and c in the address map. region a contains all the devices on the pci bus (including bridges) that the configuration code allocated befor e the hypertransport bridge. region b contains the addresses bridged to the hypertransport fabric, accesses to this address range are detected by the i/o bridge 0 and sent to the hypertransport controller directly. region c consists of the address range allocated to devices on the pci bus that were configured after the hypertransport bridge and empty space that was not allocated. when the part is running in big endian mode this area of memory accesses the pci and hypertransport using the match byte lane policy. region d (offset from the main area by setting address bit 29) is directly mapped onto the a, b and c regions, but uses the match bit lane policy. h yper t ransport e xpansion s pace there is a large region of the address space allocated to hypertransport expansion. this is marked as region n in the address map above ( figure 37 on page 193 ). this space is reserved on the BCM1125. use of this area requires the use of full 40 bit physical addresses. configuration software will also need modification to use this area (by default it will attempt to put all hypertransport peripherals in region b since they will seem to be bridged from the pci bus). the endian policy used in the expansion space is determined by the exp_endian bit in the sri command register. if this bit is clear then all of the expansion space will use the match byte lane policy. if the bit is set then address bit [38] is used to select the endian policy and the address bit is cleared as the request passes through the bridge. thus: exp_endian bit clear: - 80_0000_0000 - f7_ffff_ffff use the match bytes policy. exp_endian bit set: - 80_0000_0000 - bf_ffff_ffff and e0_0000_0000 - f7-ffff-ffff use the match bytes policy. - c0_0000_0000 - df_ffff_ffff map to 80_0000_0000 - 9f_ffff_ffff and use the match bits policy. c onfiguration s pace configuration cycles can be performed on the pci bus and hypertransport fabric by accessing the configuration space. again, with address bit [29] clear the match byte lane policy is used and with a[29] set the match bit lane policy is selected. see section: ?configuration of pci and hypertransport? on page 234 for a full discussion of configuration. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 195 pci i/o s pace pci, and for compatibility hypertransport, has both memory space and i/o space corresponding to the standard and i/o instructions in the x86 architecture. most pci devices are mapped into memory space, as memory mapped i/o devices (indeed the pci standard encourages this) but some use i/o space addresses. the mips architecture has no distinction between memory and i/o address ranges, so a range of memory addresses has been defined to map to pci i/o space. there is a 32 mb region allocated for i/o space transactions, covering regions h, i, j and k in the address map ( figure 37 ). when the part is running in big endian mode these regions use the match byte lane endian policy. the i/o address consists of only the low 25 bits of the address, for a 32 bit pci i/o address bits 31:25 are set to zero. region h is special and is discussed in the next section. region i is the space allocated to i/o devices on the pci that are configured before devices on the hypertransport, these are accessed using pci i/o reads and writes. region j is allocated to devices that are behind the hypertransport bridge and use i/o addresses, these are accessed by adding the 25 bit i/o address to the base address ( fd_fc00_0000 ) of the special area on the hypertransport defined for signalling i/o transacti ons. region k covers any pci devices that were configured after the hypertransport ones. region m (offset from the main i/o space area by setting address bit 29) is directly mapped onto the h-k regions, but uses the match bit lane policy. t he s outh b ridge , vga and s ubtractive d ecode in most x86 systems there is a device called the southbridge that connects to the pci bus and provides the interface to a number of slow speed i/o devices (serial ports, parallel ports, keyboard, mouse, more recently usb) and legacy buses (normally the isa bus), it also contains the legacy interrupt controller (often known as the pic, after the original peripheral interrupt controller chip). the interface supports the use of a single southbridge device, which can either be on the pci bus, bridged from the pci bus, on the hypertransport fabric or bridged off the hypertransport fabric. there are two problems with addressing i/o devices in a legacy southbridge: the i/o addresses of peripherals in the southbridge are normally at the location they have historically been. these addresses are not contiguous, so do not fit well into the pci address allocation model. if the southbridge connects to an isa bus, there is no easy way to know the memory or i/o addresses of devices on the isa bus. on pci buses subtractive decode is used to access these addresses. any address that is not claimed by a device on the bus is claimed by the southbridge and used by its internal devices or passed to the isa bus. as of pci 2.2 the southbridge may be behind a (or a series of) pci-pci bridge(s), the configuration software notices this and sets up all the bridges on the path to act as subtractive decode bridges. on hypertransport there is no way to do subtractive decode. normally commands whose address is not actively decoded and claimed will reach the end of the fabric and an nxa error will be raised (revision 1.0 and later of the hypertransport standard allows the device at the end of the chain to perform a subtractive decode). instead, the standard allows packets to be marked with the compat bit, this overrides the active address decoding and will always pass the access to the southbridge (for subtractive decode). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 196 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r there is a reset time configuration bit southonldt (on generic bus io_ad[21]) that sets whether the route to the southbridge is via the pci bus or hypertransport fabric. this is done as a hardware configuration option to allow use of the southbridge before the pci bus and hypertransport fabric have been configured (this is in line with section c.3 of the hypertransport specificat ion rev 0.17, and section e.3.1 of the hypertransport specification rev 1.0). the pci and hypertransport dev ice enumeration will discover the southbridge as it configures the system and can check that the southonldt bi t is set correctly (if it is not correct there is a serious hardware error, or an option card has been added with a new southbridge -- both these events should be reported). if the southbridge is reached through the hypertransport bridge then the configuration software should check (and possibly configure, if they ar e not also setup in hardware) any hypertransport- hypertransport and hypertransport-pci bridges on the route to accept and forward packets with the compat bit set (and from there on set any pci-pci bridges to do subtractive decode). if the southbridge is on the direct pci bus or is bridged from there by anything other than the internal hypertransport bridge (which logically appears as if on the pci), then the southonldt bit must be clear (and any bridges off the pci must be set to do subtractive decode). since subtractive decode is only used for legacy devices it will only be used for i/o addresses in the bottom of the range. in this interface, locations in the first 32 kb of the i/o address space can only be used for the legacy subtractive decode devices. this area is shown as region h in figure 37 on page 193 . any access to this range will be directed according to the southonldt bit, if it is set they will be sent out as hypertransport requests with the compat bit set, if it is clear they will be sent to the pci for subtractive decode. (on the BCM1125 the access is always made to pci.) similarly, the bottom 16 mb of the memory space region is used for subtractive decode only. if the southonldt bits is set any accesses in this region will be sent on the hypertransport bus as a 24 bit address with the compat bit set, otherwise they are sent on the pci for subtractive decode. the other legacy device that the pci and hypertransport specifications have as special is the vga display controller. this has historically used memory addresses 0a_0000 - 0b_ffff in the address map and registers x3b0 - x3bb and x3c0 - x3df in i/o space (per pci spec ad [15:10] are ignored for this decode). these addresses are in the compatibility regions. rather than being routed based on the southonldt configuration bit, the vga range is routed using the vgaen bit in the hypertransport bridge control register. if the vgaen bit is clear (indicating the bridge should not forward vga accesses) vga accesses are done to the pci bus, if the vgaen bit is set the access is sent to the hypertransport fabric but the compat bit is not set allowing the request to be routed by address to the vga controller. as with all the compatibility space accesses the address is masked to a 24 bit address with the upper bits zero. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 197 compatibility space routing is summarized in the pseudo-code below: if (00_4000_0000 <= zbaddr <= 00_7fff_ffff) { pcildtaddr = zbaddr & dfff_ffff endian = zbaddr[29] ? match bit lanes : match byte lanes if (pcildtaddr < 00_4100_0000) /* note after a[29] removal */ { if (pcildtaddr[23:17] == 7'b0000101) /* 0a_xxxx/0b_xxxx */ { if (bridge control vgaen) send (pcildtaddr & 00ff_ffff) to ht with compat bit clear else send (pciaddr & 00ff_ffff) to pci } else { if (southbridge is on ldt) send (pcildtaddr & 00ff_ffff) to ht with compat bit set else send (pciaddr & 00ff_ffff) to pci } } else if (ht mem base <= pcildtaddr <= ht mem limit) send to ht else send to pci } bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 198 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r for i/o space: if (00_4000_0000 <= zbaddr <= 00_7fff_ffff) ioaddr = (zbaddr & 1ff_ffff) endian = zbaddr[29] ? match bit lanes : match byte lanes if (ioaddr < 000_8000) { if ((ioaddr[24:16] == 0) && (((ioaddr[9:4]==3b) && (ioaddr[3:2]!=2'b11)) || (ioaddr[9:5]==5'b11110) ) ) { /* 3b0-3bb or 3c0-3df */ if (bridge control vgaen) send to ht (fd_fc00_0000 + ioaddr) with compat bit clear else send to pci ioaddr as i/o access } else if (southbridge is on ldt) send to ht (fd_fc00_0000 + ioaddr) with compat bit set else send to pci ioaddr as i/o access } else /* ioaddr >= 000_8000 */ { if (ht bridge header io base <= ioaddr <= ht header io limit) send to ht (fd_fc00_0000 + ioaddr) else send to pci ioaddr as i/o access } } h yper t ransport e nd o f i nterrupt (eoi) s ignaling s pace the hypertransport interrupt scheme is discussed in detail in section: ?hypertransport interrupts? on page 48 , which describes all the interrupts on the part. the hypertransport level sensitive interrupt messages require an end of interrupt (eoi) acknowledgement to clear them when the interrupt processing is complete. this is sent as a broadcast message in the hypertransport address range reserved for interrupt messages. the interface allows an eoi to be generated by doing a write to the eoi section of the address space, which is marked as region e on the address map ( figure 37 on page 193 ). bits 23:16 of the address accessed should be the vector number being acknowledged, bits 15:5 should be zero, bits 4:2 are the message type (mt) field and must be set to 3?b111 to indicate an eoi. the data written is discarded. (any access to this region will be converted into the broadcast, but it is inadvisable to do a read to generate the eoi since the data returned will be unpredictable and since the processor would be doing an uncached access it is likely to stall the cpu for no good reason). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 199 in addition to generating eoi this space can be used to generate hypertransport interrupt messages. if bits [4:2] of the address are not equal to 3'b111 (i.e. the message is encoding something other than an eoi) rather than sending a posted broadcast message the bridge will send a posted sized byte write with a count of zero, the compat bit clear and a doubleword of zeros as byte masks (the extended destination bits from rev 1.01 and later of the hypertransport standard are not supported). this is the format of an interrupt message. the address bits 23:16 indicate the vector, bits 15:8 the destination, bit 7 is reserved and should be zero, bit 6 indicates the destination mode, bit 5 should be zero to indicate an edge interrupt (level cannot be used because the interface will not accept the inbound eoi), and bits 4:2 are the interrupt type. l egacy i nterrupt a cknowledge (iack) s pace legacy interrupts from a pic style interrupt controller in the southbridge require an interrupt acknowledgement (iack) cycle, this is a byte read that will return th e interrupt source vector num ber. as with the subtractive decode i/o space, the part supports the southbridge being on either the hypertransport bus or the pci as set by the southonldt configuration bit. if the southbridge is on the pci then it will signal the interrupt using its intr pin, which should be routed to one of the general interrupt inputs. if the southbridge is on the hypertransport then it signals the interrupt using an ext. int. message, which is translated into interrupt 54 being raised in the cpu interrupt mappers (see section: ?hypertransport interrupts? on page 48 ). in either case the interrupt must be acknowledged with an iack cycle. this is a byte read that returns the interrupt vector information. the address map defines the region f (in figure 37 on page 193 ) for the cpu to read from to perform an iack access; the address is ignored and any access in this range has the same effect. if the southonldt bit is set this gets run as a cycle on the hypertransport to the special address range ( fd_f900_0000 - fd_f90f_ffff ) with the compat bit set. if the southonldt bit is clear, the read gets run as an iack cycle on the pci bus. pci f ull a ccess s pace regions o and p in figure 37 on page 193 are provided to allow the cpu to generate any memory space address on the pci bus. when the interface is configured in device mode the address map used on the pci bus matches the host system and not the internal address map. the full access space allows the device to access any host system address, as would be expected for a pci peripheral. the bottom 32 bits of the address are used directly to form the pci bus address. address bit [32] is used to select between the two regions and therefore the endian policy used for accesses. the full access space is available when the interface is in host mode, but it is less useful. the pci interface will not respond to requests that it generates, any access through full access space to an address with a destination in the part will result in a master abort. there is no equivalent i/o full access space, since the normal i/o space can be used in device mode to generate 25 bit i/o addresses on the pci bus. s pecial h yper t ransport s pace the hypertransport defines a range of address space for other special cycles. none are directly supported by the interface, however access is provided to the special range using region g in figure 37 on page 193 . use of addresses in this region requires understanding of the hypertransport specification. since no assistance is provided for the special use, accesses in this region may not be useful, and can result in undefined behavior. address bit [29] is used to select between the endian policies. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 200 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r h yper t ransport r ead r estrictions the hypertransport interface maps read requests from the zbbus into read commands on the hypertransport fabric. the interface supports all requests that can be generated by cpu instructions (reads of 1-8 bytes and 32 bytes) and any request that includes an aligned number of 32-bit words. care must be taken when using uncached accelerated accesses from the cpu or the data mover, since these can generate accesses that are not supported and will have undefined results. for best performance the zbbus read should translate into a single hypertransport request, accesses that are 1-4 bytes translate directly to a read (sized) byte request, and accesses that are an aligned number of 32-bit words translate to the read (sized) doubleword request. the interface is able to split zbbus reads into two hypertransport requests allowing the 5-7 byte reads that the load doubleword left (ldl) and load doubleword right (ldr) instructions can generate, but the interface is not optimized to give these unusual accesses high performance. there is no constraint on writes, the interface supports arbitrary writes of 1-32 bytes. any zbbus write can be converted into a write (sized) hypertransport request. there are no constraints on inbound accesses. all legal ht read and write requests are supported. (requests larger than 32 bytes will be converted into two requests to the zbbus but this is transparent to the ht fabric.) user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 201 e ndian p olicies the system can be run either as a big endian system or as a little endian system. both the pci bus and hypertransport fabric are little endian. when the part is running big endian there are two policies that are used for connecting to the interfaces. selection of endian policy is made based on address bits for requests going both from the system to the pci bus or hypertransport fabric and from the pci bus or hypertransport fabric to the system. peer-to-peer accesses between the pci bus and hypertransport fabric are always passed directly. in most cases address bit [29] being clear indicates that the match byte lane policy will be used, and address bit [29] being set indicates the match bit lane policy will be used. the address bit used to select the endian mode is zeroed as the request passes through the interfaces so that the target always see the match bytes? address. l ittle e ndian s ystem : n o s waps when the part is run as a little endian system there is no need to do any swapping between the system and pci or hypertransport. if the system configuration register is set for little endian then no swapping is done, and the two access addresses become aliases. this is illustrated in figure 38 . at the top this shows a double-word with the bit numbers and byte addresses used by the cpu and zbbus. below it shows how the bytes of the double-word will appear on the pci byte lanes. the pci uses byte enables to indicate both the transfer size and the low two address bits, these are shown as the be#[3:0] signals. figure 38: little endian system h g 63 56 55 f e 48 47 d c b a 4039 32 31 24 23 16 15 8 7 0 byte address [2:0] 111 110 101 100 011 010 001 000 dc b a 31 24 23 16 15 8 7 0 h g f e 31 24 23 16 15 8 7 0 pci bus a [2] = 0 pci bus a [2] = 1 pci byte enables be#[3] be#[2] be#[1] be#[0] bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 202 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r b ig e ndian s ystem : m atch b yte l anes the match byte lanes endian policy will match the byte lanes of 32 bit values on either side of the interface. this preserves the memory address ordering between the zbbus and pci or hypertransport. however, it will scramble the bit ordering. consequently a 32 bit value that is written into a pci register from the cpu will have a different interpretation. the policy is illustrated in the figure 39 . this is similar to figure 38 on page 201 , except that from the cpu the mapping from bytes of the double-word onto addresses is reversed. when the data is passed to the pci/ hypertransport the address order is maintained and the low two address bits directly set the pci byte enables. the little endian nature of the pci is exposed to the processor. if a value is stored from a cpu register into a peripheral device register its bytes will be reversed. figure 39: match byte lane endian policy if a sequence of bytes is moved through the interface the address of each byte is maintained, so the order of the sequence is maintained between the pci or hypert ransport device and memory. therefore this is the correct endian policy to use for most dma transfers. this policy is also the correct one to use for configuration and control register accesses if the software is written to explicitly endian swap the values in big-endian systems. however, since most drivers will be ported from little endian systems they are unlikely to have the endian swap code. it will normally be better to avoid the software overhead and use the match bits policy for control functions. a b 63 56 55 c d 48 47 e f g h 4039 32 31 24 23 16 15 8 7 0 byte address [2:0] 000 001 010 011 100 101 110 111 d c b a 31 24 23 16 15 8 7 0 h g f e 31 24 23 16 15 8 7 0 pci bus a [2] = 0 pci bus a [2] = 1 pci byte enables be#[3] be#[2] be#[1] be#[0] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 203 b ig e ndian s ystem : m atch b it l anes the match bit lanes endian policy will match the bit numbers of 32 bit values on either side of the interface. in byte lane terms this is an endian swap of the data. consequently a 32 bit value that is written into a pci register from the cpu will have the same interpretation. this policy is therefore the correct one to use when setting up configuration registers, passing addresses, and most control functions. the policy is illustrated in figure 40 . compared to figure 39 on page 202 , the bit ordering is maintained going from the system to the pci. the pci byte enables are generated from the inverse of the bottom two system address bits reflecting the different byte significance between the two sides of the interface. figure 40: match bit lane endian policy by matching the bit number in 32 bit words, the bits that the cpu uses will match with the register descriptions in the pci peripheral data sheet. similarly, an address written into a control register from a cpu register will have the same meaning. note that the situation is more complicated for 64-bit accesses (see below), but these are forbidden by the hypertransport specification for configuration accesses to the hypertransport space, and forbidden by the bridge for accesses to the pci configuration registers. if a byte access is performed the programmer will get the expected result for a big-endian context, i.e. the most significant bits of the register will be at the lowest cpu byte address. similarly a 16 bit access will be mapped in the way expected for a big-endian machine. a sixty-four bit access performed by the cpu will be split into two thirty two bit accesses, again the data will end up in the positions consistent with a big-endian model. the problem with this policy is that the byte memory ordering is scrambled since the byte lanes are swapped. this affects bulk data transfer, where the device on the pci or hypertransport assumes that the order on the byte lanes matches the memory order with be#[0] associated with the lowest memory address. therefore this mapping is unlikely to be useful for devices doing dma accesses into the system memory. it is useful for access to control registers (where it will save endian swapping in software). the match bits policy can also be used if the peripheral can be configured for big endian dma operation. a b 63 56 55 c d 48 47 e f g h 4039 32 31 24 23 16 15 8 7 0 byte address [2:0] 000 001 010 011 100 101 110 111 a b c d 31 24 23 16 15 8 7 0 e f g h 31 24 23 16 15 8 7 0 pci bus a [2] = 0 pci bus a [2] = 1 pci byte enables be#[3] be#[2] be#[1] be#[0] bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 204 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r as an example consider accessing control registers with the same layout as the standard pci header (this layout is used only as a familiar one for the example, the interface does not allow 64 bit accesses in configuration space so this cannot be used directly). looking at the fields at offsets +0 and +4 with a big endian viewpoint the expected behavior for a 64 bit read should give the data at low memory address in the high (big) end of the register: 63:48 device id 47:32 vendor id 31:16 status 15:0 command this is what a 64 bit read using the match bits policy will give. looking at a pci 64 bit bar instead of the control registers (or equivalently a 64 bit dma address register) shows that 64 bit accesses will not work directly for access to 64 bit addresses in hypertransport peripherals. a 64 bit bar would span two 32 bit words, but has the low address bits in the first word and the high address bits in the second word. looking at this picture with the big endian viewpoint (as above) the 64 bit read will give: 63:32 low address bits 31:0 high address bits this is word swapped compared to what would be ideal, but is still consistent with the 64 bit world-view because it was originally defined as two 32 bit quantities. v iewing e ndian p olicy as an o ptimization one way to view the endian policy selection is as a way to optimize code. this section considers the software viewpoint assuming a portable operating system is being used. to summarize the issue: the pci/hypertransport bus and peripherals are little endian, thus when storing a 32 bit value in a register the least significant byte (i.e. bits [7:0]) are assigned to the lowest memory address. when an access is done from a big endian cpu, which stores a 32 bit value with the most significant byte in the lowest memory address, the data appears swapped. consider a 32 bit control register in the pci device that contains the 32 bit value 32'h12345678, on the pci bus the byte containing '78' will be on the byte lane with the lowest memory address marked with cbe[0] asserted. if the cpu does a read it will place the lowest memory address into the high bits of the register so will see the 32 bit value 32'h78563412. in most multi-platform operating systems the first cut way of fixing this is to put an endian swap in if required: #ifdef big_endian /* need to swap the bytes */ result = endian_swap(*pci_reg_address); #else /* on a little_endian system can read directly */ result = *pci_reg_address; #endif this will work as expected using the match bytes access area of the pci/hypertransport regions. the match bits space allows the hardware to automatically do the swapping. a single physical address bit (bit [29] in the standard memory mapped i/o space) is set to switch from match bytes to match bits. so the code can become: #ifdef big_endian /* get hardware to swap the bytes */ result = *(pci_reg_address | bytes_to_bits_address_bit); #else /* on a little_endian system can read directly */ result = *pci_reg_address; #endif user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 205 this is an optimization because the endian swap is several instructions compared to the single or (and in many cases all of the control registers need the swap so the base address of the control block can just be offset once; or if all the control registers are mapped in a single tlb entry and the data accesses in another then the virtual to physical mapping could set the match bits address bit for control and not for the data ranges). the standard address is the match bytes since this makes memory order correct and thus causes unoptimized (but endian aware) code to work correctly. a ccessing the s i b yte from pci d evices the normal pci base address register (bar) access scheme is used to accept accesses from the pci bus and map them to internal accesses. the pci bus uses 32 bit addresses. to allow pci masters to do transfers to memory, other devices in the part and peer-to-peer transfers to devices on the hypertransport a full 40 bit address must be constructed. with the exception of expansion memory space and expansion hypertransport space the part places everything in the low 4g of the address space (physical address bits [39:32] are zero) allowing a direct map from the 32 bit address on the pci bus. in addition there is a map table that allows each of sixteen 1 mb regions of pci space to map to a full 40 bit address anywhere in the internal or hypertransport space. the pci controller has a type 0 (device) configuration header. this allows for up to 6 bars, 5 are used when the interface is in host mode and 3 are used when the interface is in device mode. in addition a pci expansion rom may be accessed through its special bar. table 123 shows the bars and the internal addresses that they map to. in host mode they default to the values shown and are enabled following reset (if transparent access from pci is all that is needed then no changes are required by the configuration code). when the interface is run in device mode the bars will be setup by the host (using addresses in the host space). note that the table shows the addresses. since the spaces are prefetchable the value in the pci bar register will have bit 2 set. table 123: pci base address register use reg offset in config header pci size default pci base address in host mode pci base address in device mode internal base address internal device bar0 +10 16m 6000_0000 (r/o) xx00_0000 table lookup region controlled by map table. bar1 +14 0 0000_0000 0000_0000 - reserved bar2 +18 4k 7000_0000 (r/o) xxxx_x000 00_1002_1xxx mailbox cpu 0. match bytes mode is used if the system is configured big endian. bar3 +1c 4k 7100_0000 r/o xxxx_x000 00_1002_3xxx mailbox cpu 1. match bytes mode is used if the system is configured big endian. bar4 +20 1g 0000_0000 (r/o) reserved 00_0000_0000 memory below pci space (pci a[29] indicates endian policy). bar5 +24 2g 8000_0000 (r/o) reserved 00_8000_0000 memory above pci space (pci a[29] indicates endian policy). rom +30 64k 7300_0000 (r/o) xxxx_0000 00_1fd0_xxxx expansion rom. match bytes mode is used if the system is configured big endian. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 206 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r addresses on the pci that match in bar0 are mapped into internal addresses using a mapping table illustrated in figure 41 on page 206 . this allows a pci device to access any area of in the internal address map, and can be used to ensure pci devices can only access specified memory areas. the 16 mb region is divided into 1 mb chunks. pci address bits [23:20] are used to index into a table which provides address bits [39:20] of the internal address to use and an enable bit. the low bits [19:0] for the internal address are copied directly from the pci address. if the table entry is enabled then the request on the pci bus is accepted (devsel# asserted) and the transaction is made to the internal address. if the table entry is not enabled then the bus request will not be accepted (devsel# will not be asserted) and the requester will see an error. there is also a bit in the entry that controls whether the access is sent to the hypertransport fabric or used internally (this bit overrides the destination implied by the address, so software must take care to set it correctly). if the bit is set to send the request internally and the address is in the hypertransport range the result is unpredictable, but in most cases a target abort error will be returned. if the bit is set to send the access to the hypertransport and the address is in the internal range then the result depends on the devices on the hypertransport, in most cases the request will reach the end of chain without being accepted, an nxa error will be returned and be turned in to a target abort, but if there is a host at the other end of the chain then it may unexpectedly reply. if the request is sent in to the part then two more bits in the map entry set the endian policy to be used for the transfer and the state for the level 2 cache allocate on miss (a_l2ca) flag that should accompany the transfer. the mapping table is placed in configuration registers h44 - h80 in the pci configuration header, however they can only be set by accesses from the zbbus side of the bridge (even when in device mode). figure 41: pci bar0 address mapping table pci bus address bar0 31 24 23 2019 0 match map 0 ( reg h44 ) map 1 ( reg h48 ) map 15 ( reg h80 ) ht/zbbus address 39 20 19 0 enable send toht index l2ca flag endian policy user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 207 bar2 and bar3 provide access to the cpu mailbox registers (see section: ?mailbox registers? on page 46 ). the pci device can read the current value of the mailbox and do writes to set bits in the mailbox, but it is not able to clear the mailbox. the pci device can therefore raise interrupts to the cpus, send small messages, and read status, but is prevented from directly clearing any cpu interrupts. this access is provided in both host and device modes (but will most likely be used in device mode). bar4 is only available in host mode. there is an enable/disable bit for this bar in configuration register h40, it is enabled after system reset. the bar provides a direct map from the pci to the bottom 512 mb of the system memory using the match byte lane endian policy, and (by setting a[29]) a map from the pci to the bottom 512 mb using the match bit lane policy. (this area covers the low memory area, internal devices and some of the generic bus space). the interface will use pre-fetches for any reads in this area. bar5 is only available in host mode. there is an enable/disable bit for this bar in configuration register h40, it is enabled after system reset. the bar provides a direct map from the pci to the two 512 mb sections of memory 00_8000_0000 - 00_9fff_ffff and 00_c000_0000 - 00_dfff_ffff using the match byte lane endian policy, and (by setting a[29]) a map from the pci to the same two areas using the match bit lane policy. (these areas cover the rest of the memory that is addressable with 32 bit addresses, they also cover the cache test space and special access addresses that should not be accessed by normal pci devices). the pci expansion rom access bar is mapped to 64 kb of the space that is allocated to the boot rom at reset time. this allows an external pci host to access an expansion rom with no setup required by the cpu (preventing reset ordering problems). the bottom bit of the bar must be set to enable the region (as required by the pci specification). reads on the pci do not explicitly indicate a length. to optimize performance the pci bridge will always prefetch a cache line (i.e. do a read on the zbbus with all byte enables set) when a read to the part comes in from a pci device. when memory accesses are made the i/o bridge will do a coherent read and this will work as expected. if an access is made (through bar4 or bar5 or the rom bar or mapped to through bar0) to any non-memory space in the part the i/o bridge will do an uncacheable read with all byte enables set. the result of this read will depend on the device accessed: memories on the generic bus will be read correctly, reads of internal registers that are cacheline aligned (i.e. a[5:3]=0) will work as expected, but reads of internal registers that are not cacheline aligned will give unpredictable results. writes on the pci do not explicitly indicate a length. the pci bridge will gather a burst write targeted at the system into a buffer and do a write with the appropriate byte enables set. if the write is to memory space and all the byte enables are set a write-invalidate is sent on the zbbus to write the data and invalidate old copies that are in any caches. if the write is to memory space and less than the full 32 byte enables are set the i/o bridge will perform a coherent read exclusive to get ownership of the block, the write data will be merged and the block written back. the bridge acts as a full participant in the coherency protocol, so if there is any request for the line it will respond as owner and will provide the data. if the write is to non-memory space an uncacheable write is performed on the zbbus with the byte enables reflecting the bytes that were written in the pci transaction. writes to internal registers or the generic bus will therefore work as expected. figure 42 on page 209 shows the memory map that is seen from the pci bus after reset on with the interface configured in pci host mode. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 208 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r once the pci interface has accepted a transaction that hits in one of the bars (by asserting p_devsel_l) it will complete or be terminated with a target abort. there are four classes of problems that will cause target abort: 1 an error is detected on the pci bus. this could be a parity error, an illegal opcode or illegal byte masks. 2 an error is returned from a read request that has been sent to the zbbus (this will be logged by the bus watcher) or to the hypertransport interface (this will be logged in the interface csrs). 3 the request hit in a bar and targets the hypertransport interface but the ptp_en bit in the feature control register is clear, disabling peer-to-peer transfers from pci to ht. 4 the request hit in a bar (in particular bar0) and was targeted at the zbbus, but the (mapped) address targets a pci or hypertransport space (i.e. one serviced by i/o bridge 0). an access that hits in bar0, but to a disabled map entry, will not be accepted (p_devsel_l will not be asserted). this results in a master abort. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 209 figure 42: default host mode memory map from pci bus master upper memory (b) bar 5 bar 5 expansion rom forward to ht pci range bar 4 scd first dram region boot rom internal devices unused pci/ht config 8000_0000 6000_0000 4000_0000 0000_0000 01_0000_0000 00_a000_0000 00_0000_0000 upper memory (b) match bit endian policy match byte endian policy upper memory (a) bar 5 match bit endian policy upper memory (a) bar 5 match byte endian policy unused bar 3: mailbox cpu1 bar 2: mailbox cpu0 unused bar 0:maps anywhere through table (host bridge ignores) low memory match bit endian policy bar 4 low memory match byte endian policy 2000_0000 6100_0000 7000_0000 7100_0000 7200_0000 7300_0000 dram maps to 00_d800_0000 - 00_dfff_ffff with match bit endian policy pci/ht i/o space ht/pci special l2 direct access fourth dram region third dram region second dram region pci/ht memory space match bit endian policy 00_1000_0000 00_1006_0000 00_1009_0000 generic bus devices (default for io_cs0) 00_1fc0_0000 00_2000_0000 00_4000_0000 00_6000_0000 00_8000_0000 00_9000_0000 pci/ht memory space 00_f800_0000 00_e000_0000 00_de00_0000 00_dc00_0000 00_d800_0000 00_d000_0000 00_c000_0000 e000_0000 c000_0000 a000_0000 match byte endian policy 00_1fd0_0000 00_1fe0_0000 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 210 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r a ccessing the s i b yte from h yper t ransport d evices the mapping from hypertransport addresses to those in the part is much simpler than from pci. it is shown in figure 43 . figure 43: memory map from hypertransport device interrupt packet map to 0x_xxxx_xxxx map to 00_xxxx_xxxx send back out on ht and send on zbbus (match bytes) send on pci send on zbbus peripherals dram ht memory space pci memory space dram /l2 cache memory expansion space ht expansion space ht address sibyte d evice ff_ffff_ffff fd_fe00_0100 f0_0000_0000 e0_4000_0000 80_0000_0000 00_8000_0000 00_4000_0000 00_0000_0000 ff_ffff_ffff 80_0000_0000 00_0000_0000 fd_fe00_0000 reserved (nxa) configuration registers device = 0 function = 0 fd_f900_0000 reserved (nxa) accept and forward to scd fd_f800_0000 f1_0000_0000 reserved (nxa) send on pci using lower 32 address bits e0_8000_0000 e0_0000_0000 map to 00_xxxx_xxxx and send on zbbus (match bytes) send to pci or ht (southonldt bit) peer-to-peer ht transfer if srcid nonzero send back on ht if srcid is zero return nxa a[29] sets endian policy send on zbbus a[29] sets endian policy send on zbbus a[38] sets endian policy 01_0000_0000 e8_0000_0000 send on pci/ht (southonldt bit) 00_4100_0000 00_6000_0000 reserved (nxa) send back out on ht send on pci e0_4100_0000 e0_6000_0000 reserved (nxa) map to 00_xxxx_xxxx map to 00_xxxx_xxxx e8_8000_0000 e8_4000_0000 reserved (nxa) map to 00_xxxx_xxxx and send on zbbus (match bits) map to 0x_xxxx_xxxx (bit 35=0) and send on zbbus (match bits) bounce space map and send on ht fd_0000_0000 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 211 the hypertransport interface always runs as a host bridge, and has a pci type 1 configuration header. the base and limit registers in the header define the region of the pci/hypertransport memory space that is allocated to devices on the hypertransport fabric (these devices can be accessed by a system that uses 32 bit addresses). the value of the southonldt configuration bit determines whether the 00_4000_0000 to 00_40ff_ffff range is allocated to the hypertransport or pci (note that these addresses are not changed when they are forwarded, nor will the compat bit be set if the request is sent back out on the ht). in addition the hypertransport is allocated the top half of the full 40 bit physical address space. if the bus master enable bit is clear in the hypertransport interface bridge header the only requests that will be accepted from the hypertransport fabric are to the configuration space. all other requests will be discarded or receive an nxa response. if this bit is set the bridge will accept transactions to be forwarded to the zbbus, pci bridge and back to the hypertransport. peer to peer operations on the hy pertransport fabric must pass thr ough the host bridge, any incoming addresses that match a hypertransport region are t herefore forwarded to the outgoing link. requests with srcid=0 to hypertransport peer-to-peer are responded to with an nxa (non existent address) error since they must have come all the way from a host bridge at the other end of the link and not been accepted by any of the devices on the link. requests that match a pci address, either using standard addresses in the low 32 bit range of the address map or in the special f0_0000_0000 - f0_ffff_ffff range, are forwarded to the pci interface and a pci cycle is run. a pci cycle is also run for accesses to the southbridge space if the southonldt bit is clear. the data is passed directly between the two interfaces regardless of system endian settings. only a single hypertransport-pci read will be issued at a time. the pci interface will not respond to requests that it generates, any access forwarded from the hypertransport fabric that match a pci address with destination inside the part will result in an error. requests that match the zbbus space will be forwarded through i/o bridge 0 and run as internal cycles. these requests use one address bit to select the endian mode for the transfer. if the system is big endian then setting the address bit will result in the match bit lane policy and leaving it clear will give the match byte lane policy. if the isochronous bit is set in a hypertransport request that is sent to the zbbus, it will have the l2 cacheable bit set in the command. this is particularly useful if the hypertransport device is writing data that one of the cpus will need immediate access to. if the address is to the memory range then a cacheable coherent access is made. if the access is a write of smaller than a cache line then the i/o bridge will get the current data and ownership of the block by using a read exclusive command, the new data from the write is merged into the block and it is written back to memory or l2. if the address is not in the memory range then an uncacheable access is used, with the appropriate byte enables set. if an error is returned from a zbbus read the mstrabortmode bit in the bridge control register determines the error reported to the hypertransport fabric. if the bit is set a hypertransport error with the nxa bit clear is generated for all zbbus error types. if the bit is cl ear, zbbus bus errors or fatal errors cause unpredictable data marked valid to be returned to the hypertransport fabric, but other zbbus errors are still returned as hypertransport errors with the nxa bit clear. non-posted writes will never return an error, since they are converted to posted writes internally. the interface does not accept cycles based on the compat bit being set (even if the southonldt flag is clear), it therefore cannot be used to forward from the hypertransport to a southbridge on the pci bus. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 212 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r force isochronous mode address range allowing the isochronous bit to set the l2 cacheable bit on the zbbus is useful for new devices that support setting the isochronous bit during requests, but cannot be used by devices that do not allow control of the isochronous bit or that are bridged from other buses by a bridge that will not translate requests appropriately. therefore for revisions revid 3 or greater of the ht interface there is an additional bar (the isocbar) and mask (the isocignmask) that is used to specify a range of addresses that will be forced to behave as if the isochronous bit is set. the function is enabled when bit [0] of the isocbar is set. the isocignmask is used to indicate which bits should be ignored when the address from a ht request is compared with the isocbar. if the other bits match between the received address and the isocbar then the isochronous bit in the request is forced to be set and the l2ca flag will be set on the zbbus. the isochronous bit is forced if: (htaddr[35:5] | isocignmask[31:1]) == (isocbar[31:1] | isocignmask[31:1) in addition to allowing the pci bar style power-of-two windows this allows for more complicated situations. for example consider the configuration: isocbar = 32'h08120001 isocignmask = 32'h0200ff02 this defines a 1mbyte region with base 00_8120_0000 in which the isochronous bit will be forced for the first 64 bytes in every 4k (since addr[11:6] must be zero and addr[5] is ignored). bit 25 of the isocignmask is set to ignore address[29] since that is only used to set the endian policy. assuming buffer alignment this could be used to allow packet headers to be cached and bodies to be written to memory. note that bits [39:36] are always ignored in the comparison so that the ex_xxxx_xxxx address will have the same l2ca behaviour as the 0x_xxxx_xxxx address that it maps to. a ccessing the s i b yte from a s i b yte on a d ouble h osted c hain the interface provides limited support for double-hosted hypertransport chains. this is primarily intended for interconnection of two bcm1250s, two BCM1125hs or a bcm1250 to a BCM1125h. the ht configuration registers are accessible from the hypertransport fabric as device=0 function=0. at system startup one part must be designated the master, and the other the slave (this could be done by using the reset configuration resistors that are allocated for software use, or by having different bootstrap code on the two devices). the master will configure the chain as described in the hypertransport specification. the two parts can communicate over the fabric. since they have the same address map, a mapping must be provided to allow each access to the other's memory space. this is done in a simple manner using a direct map. accesses from the zbbus to the region of the address space e0_0000_0000 - ef_ffff_ffff will be sent to the hypertransport fabric (since it is in region n in figure 37 on page 193 ). this range will be accepted by the host bridge on the part on the other end of the fabric, and direct mapped into the low address space ( 00_0000_0000 - 0f_ffff_ffff ) and a second level decode performed to determine if the request should be forwarded to the zbbus, the local pci or sent back out on the hypertransport. accesses to these addresses pass over the i/o fabric and therefore outside the coherency domain. software will need to manage the coherency of any data between the two parts. the space should be mapped either uncacheable or cacheable non-coherent in the cpu, and will not be cached in the l2 cache. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 213 accesses from the zbbus of one part to the f0_0000_0000 - f0_ffff_ffff region of the address map will be sent over the hypertransport fabric, accepted by the second part and direct mapped to a pci access on the second device. there is a restriction on configuration accesses made from one part to another over the hypertransport link. both reads and writes to the configuration registers must be 32 bit operations (a hypertransport full unmasked double-word), if bigger or smaller operations are performed reads will return unpredictable values and writes will leave the configuration register in an unpredictable state. interface revid 3 and later support the actasslave function defined in the hypertransport 1.03 specification, which is of use in some double-hosted configurations. hypertransport bounce space in a double-ended chain is used with a master host on one end and a slave on the other, peripherals will identify the master device and direct all transactions to it. anything that matches a memory address will be accepted by the master. the slave has an identical memory map, so direct transactions will never reach it. the bounce space provides a way for the peripheral to bounce transactions to the slave via the master. any address received in the range f1_0000_0000 - fb_ffff_ffff will be sent back out on the hypertransport fabric with the address mapped to 01_0000_0000 - 0b_ffff_ffff (the top 4 bits are cleared) and any address received in the range fc_0000_0000 - fc_ffff_ffff will be sent back out on the hypertransport fabric with the address mapped to 00_0000_0000 - 00_ffff_ffff (the top 8 bits are cleared). this allows the device to access the memory space in the slave. p erformance of the pci and h yper t ransport i nterfaces the performance of the pci and hypertransport interfaces is strongly dependent on the size of the transfer. the best case is when 32 byte cache blocks are moved. if smaller writes are done from the pci or hypertransport into the part then the i/o bridge 0 has to read the cache block exclusive (to fetch any modifications that may be in caches), modify it and write it back. writes from the zbbus to either interface are always posted. reads consist of two stages: the read request, which is a non-posted request; and the read-data-return (rdr) which is a response. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 214 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r a ccesses from the s i b yte to the pci or h yper t ransport the data path from the zbbus to the pci or hypertransport is split into three sections. the interface to the zbbus includes queues of requests and returning data. inside the i/o bridge there are additional buffers in the routing path to the interface block. finally, there are additional queues and tables of outstanding requests in the interface blocks. figure 44: buffers used for accesses from the zbbus to pci and hypertransport figure 44 illustrates these queues. the request queues always maintain transactions in the order that their a- phase happened on the zbbus, for uncached accesses this matches the program order of the loads and stores. once the requests are on the hypertransport fabric or pci bus the normal pci ordering rules apply, so writes can pass reads; for uncacheable accesses from the sb-1 cores this is not a problem because the cpu will not issue an uncacheable write while there are uncacheable reads outstanding. the internal connections will maintain the order of reads and the sb-1 cpu supports multiple outstanding uncached reads to allow streaming. there is one case where this can cause problems: in the hypertransport fabric (due to the ordering of the chain), or pci with bridges (using delayed reads) reads to different devices may reach their destinations in a different order than they were issued. if the reads have side effects that are signalled on a back-channel between the two devices the second read issued by the cpu may or may not see the effect of the first (this is always a danger with back-channels). if this rare situation is encountered in a system then the program must include a sync instruction between the reads to ensure they complete in the expected order. writes from the zbbus are always posted and need no reply, they pass through the request queues and are issued to the i/o bus. reads also pass through the queues to be issued, but also have associated read-data- return (rdr) passing back up through the bridge to the zbbus. queue queue zbbus queue queue queue requests queue requests if no reads queue 5 writes queue 14 reads outstanding on ht fabric queue 1 read or write outstanding on pci bus else queue 1 write 4 requests 2 rdr 2 rdr 2 rdr 4 posted 4 non-posted 2 reads 1 rdr user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 215 the hypertransport fabric uses split transaction reads and the interface supports 14 reads outstanding on the fabric. when a hypertransport response arrives it is matched to the associated request and passes back through the rdr path. if a masked read (a read that is not a multiple of aligned 32-bit words) is encountered then no further reads will be accepted by the interface until it has completed (the ldl and ldr instructions can result in reads of 5, 6 or 7 bytes, these will be split into two masked reads that can both be outstanding on the link and must both complete before the rdr is returned). the pci interface can hold one read pending and have one read in flight on the bus. if a read is retried excessively (more than the number of times set in the retry timeout register described in table 132 on page 240 ) the interface will allow any writes or rdrs to pass before retrying the read. if a read exceeds the retry timeout on the second attempt it will be abandoned and a bus error reported. the restriction on only having one read pending on the pci bus will limit the performance. therefore in interface with revid 3 or greater a prefetch mechanism is added. if prefetching is enabled in the pci adaptive extend register then a full cache block zbbus read will cause 2 or 4 cache blocks to be prefetched from the pci. this is particularly useful when the data mover is transferring a large block from the pci. if a read request from the zbbus is for a full cacheline at an aligned address and the prefetch is enabled and the address is not greater than (4k page boundary minus 4 cacheline addresses), then a read of 2 or 4 cachelines is issued to the pci. if the next request from the zbbus is also a fu ll cacheline read to the next consecutive cacheline address, the prefetched data will be returned. this pattern will repeat until all the prefetched data are returned. if the next request does not meet this criteria, the prefetched data will be flushed and the new request will be sent to the pci bus. (note that since the prefetched data could be fetched and discarded it is possible for the prefetching to lower performance.) in the error case where the prefetched data (the additional data that is not used by the initial transaction) is timed out for too many retries, the interface will not reissue the prefetch reads. this may cause the device being accessed to deadlock, to prevent this the retry limit should be set high to ensure only actual errors will be captured. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 216 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r a ccesses from the h yper t ransport to the s i b yte figure 45 shows the queueing for dma accesses from the hypertransport fabric and pci bus into the part. figure 45: buffers used for dma acc esses from the pci and hypertransport posted writes from the hypertransport fabric flow through the queues in the i/o bridge and zbbus interface and are posted on the zbbus. non-posted writes from the hypertransport become posted writes internally (since the architecture does not have any internal non-posted writes). an acknowledgment response is always sent on the hypertransport when the write leaves the hypertransport interface and is inserted in the i/o bridge queue. since it has become a posted write it may now pass reads. an error response will never be generated. reads from the hypertransport fabric pass through the queues and are sent onto the zbbus. the i/o bridge interface can have 8 reads outstanding on the zbbus (including those from both pci and hypertransport). when all 8 entries in the rdr buffer are in use further reads are blocked from moving into the zbbus request queue. the read-data-return is sent back to the cpu response queue in the hypertransport interface. read requests from the hypertransport that are longer than 32 bytes will result in two reads being issued towards the zbbus. queue up to 4 posted queue up to 4 non-posted ht queue queue queue queue pci queue queue request 1 outstanding rdr prefetch 1 block for read/readline prefetch 2 blocks read multiple 8 rdr outstanding zbbus 4 rdr 2 write 2 requests 2 requests 2 writes 1 rmw user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 217 a ccesses from the pci to the s i b yte the path for the pci to access the part is shown in figure 45 on page 216 . it is similar to the hypertransport flow. writes from the pci are always posted into the part, they flow through the queues shown in the figure. the pci interface will accept one outstanding read from the pci bus. if this read is not serviced after 16 pci cycles (the debug is programmable as described below) it will be disconnected to allow other pci devices to make progress (turning it into a delayed read request). subsequent reads from the pci bus into the part will be immediately disconnected until the first has been satisfied. pci reads do not include a length in the request, so a heuristic is used to improve performance. if the read uses a pci read or readline command the pci interface will initially request a single (32 byte) block from the zbbus interface, when this returns it will be used to satisfy up to 32 bytes of the request. if the request is still in progress an additional request will be made to the zbbus interface for the next cache block. if the readmultiple pci command is used the interface will immediately launch two read requests for consecutive cache blocks, and will continue to prefetch blocks as the data is sent to the pci. the reads share the rdr buffer in the zbbus interface with reads from the hypertransport fabric. if a request from the pci bus requests a burst mode other than linear incrementing the interface will disconnect the transfer after a single data phase. memory space reads smaller than four bytes will result in the appropriate byte enables being asserted on the pci bus unless the dis_memrd_be bit is set in the pci adaptive extend register. if this bit is set all memory space reads will have all four byte enables asserted (the additional bytes received from the pci will be ignored). if the dis_memrd_be bit is clear then any access to the pci greater than 4 bytes should be an aligned multiple of four bytes. if the dis_memrd_be bit is set then any access may be safely done but the pci device will always see an aligned multiple of four bytes. pci adaptive retry the pci specification requires that if a request is not completed within 16 cycles the target should terminate the transaction with a retry to free the bus for other devices. it encourages devices that know they have a long latency to disconnect the transaction as early as possible to avoid dead cycles on the bus. on the host the latency of memory reads is hard to calculate because it depends on what other activity is in the system. typically in a lightly loaded system reads will complete in 200-400 ns, which is well under the pci timeout. by default the interface will not retry the transaction early, and will wait the full 16 cycles before issuing the retry. the interface also has an adaptive retry policy, which is enabled by setting the adapt_retry_en bit in the feature control register ( table 133 on page 241 ). the actual latency of read requests is measured and used to set the number of cycles that the interface waits before signalling the read should retry. table 124 shows how the retry delay is changed based on the current memory latency. two consecutive samples must show the same trend in latency before the algorithm changes behavior. the adaptive retry parameters are spread across the pci feature control register and the pci adaptive extend register. the minimum value is a 3 bit field, nominal and maximum are 7 bit fields. this allows the values to be programmed well outside the compliant pci range, but allows optimal selection to be made in embedded systems. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 218 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r figure 46: pci adaptive retry parameters figure 46 illustrates the algorithm. (the suggested delay va lues are appropriate for a host bridge, which is permitted to wait up to 32 cycles before issuing a retry, compared to only 16 cycles in a device). the retry delay is initialized to the value given in the nom_tar_retry register. this sets the normal retry timeout that should be used and should be set above the delay expected for the memory system. most reads will be satisfied in this latency (falling in to the normal read latency box in the figure), and the occasional long latency accesses will be disconnected and retried (this behavior is just like the standard case). if the system becomes busier and the latency increases slightly (moving the read latency into the higher than expected load box), to fall between the nominal and maximum values, rather than continua lly disconnecting transactions just before their data becomes available the adaptive policy will increase the retry delay to the maximum value. this prevents the pci throughput falling catastrophically when the system experiences a load slightly higher than was expected. however, if the memory latency becomes larger than the maximum (the very high load box) then the retry delay is set to its minimum value causing requests to be rapidly disconnected. once the overload has been detected the retry delay is left at the minimum until the memory latency returns to its normal range, when the retry delay will also be restored to its normal value. table 124: adaptive retry delay condition new delay before retry memory latency > max_tar_retry retry_delay = min_tar_retry retry_delay != min_tar_retry and max_tar_retry > memory latency > nom_tar_retry retry_delay = max_tar_retry retry_delay == min_tar_retry and nom_tar_retry > memory latency > min_tar_retry retry_delay = nom_tar_retry 0 measured memory latency max_tar_retry (e.g. 20) nom_tar_retry (e.g. 16) min_tar_retry (e.g. 8 or less) new retry delay when memory latency detected in this range set retry_delay = min_tar_retry if (retry_delay! = min_tar_retry) retry_delay = max_tar_retry if (retry_delay = = min_tar_retry) set retry_delay = nom_tar_retry normal read latency read latency with higher than expected load read latency with very high load user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 219 p eer - to -p eer a ccesses the interface supports peer-to-peer accesses from devices on the pci bus to devices on the hypertransport fabric, and from devices on the hypertransport fabric to devices on the pci bus. requests and data being transferred in this way do not travel on the zbbus, they are directly routed through special buffers in the i/o bridge 0. in the master bus interface of a peer-to-peer operation the queues are shared with dma operations (from i/o devices into the zbbus) and on the slave side the queues are shared with pio operations (from the zbbus to i/o devices). peer-to-peer operations in i/o space are not supported. neither the pci bus nor the hypertransport bus will accept an incoming i/o space request. pci b us t o h yper t ransport f abric when the pci interface is configured in host mode, requests on the pci that fall into the secondary bus memory range specified in the hypertransport bridge header will be accepted from the pci and forwarded to the hypertransport fabric. this forwarding is disabled by default, and must be enabled in the feature control register (offset h40 in the pci configuration header). in addition requests that match bar0 and have an enabled mapping with the send_ldt bit set are forwarded to the hypertransport (the send_ldt bit overrides any destination implied by the address). the peer-to-peer bit in the feature control register must also be set to enable forwarding through the map table. if the pci interface is configured in device mode and the peer-to-peer bit is set in the feature control register the only requests that will be forwarded to the hypertransport fabric are those that hit in bar0 and have an enabled mapping with the send_ldt bit set. this allows the part to act as a non-transparent bridge (i.e. one with separate address spaces on each side and explicit routing between the sides) from the pci host to the hypertransport fabric. note that in device mode the feature control register is written by the host on the pci bus and cannot be accessed from the zbbus, thus both the host (through feature control ptp_en) and device (through bar0 send_ldt) must agree for the pci-ht access to be permitted. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 220 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r figure 47 shows the queues used in peer-to-peer operations with a pci master. peer-to-peer writes will transfer exactly the number of bytes written and will always be posted to the hypertransport fabric. they flow in their own channel from the pci interface to the hypertransport interface and may pass non-posted reads. figure 47: buffers used for pci to hypertransport peer-to-peer accesses peer-to-peer reads always assume the destination address is prefetchable (this is required for performance, since the pci bus does not give a good indication of the transfer size at the start of the transaction). caution should be used when accessing registers using peer-to-peer operations. the same algorithm is used as for reads to the zbbus, the pci read is assumed prefetchable, and is a read or readline is causes single 32 byte request to the hypertransport fabric while a readmultiple will launch two requests. queue 1 outstanding rdr pci queue queue queue queue 14 reads outstanding on ht fabric queue 2 write requests 1 write 1 read 1 rdr 4 posted 4 non-posted user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 221 h yper t ransport f abric to pci b us requests received by the hypertransport interface to any addresses that fall in the space allocated to the pci memory space (regions a and c in figure 37 on page 193 ) or that fall into the special double ended chain mapped address ranges ( e0_4000_0000 - e0_7fff_ffff and f0_0000_0000 - f0_ffff_ffff in figure 43 on page 210 ) will be forwarded to the pci interface. since the size of the transfer is specified at the start of a hypertransport request the access to the pc i bus will always be for the exact number of bytes requested. figure 48 shows the queues used in peer-to-peer operations with a hypertransport master. peer-to-peer writes will always be posted to the pc i bus. non-posted write requests will be acknowledged when they leave the hypertransport interface. writes flow in their own channel from the hypertransport interface to the pci interface and may pass non-posted reads. figure 48: buffers used for hypertransport to pci peer-to-peer accesses the hypertransport interface can have two reads outstanding to the pci interface. if a hypertransport request is for more than 32 bytes both outstanding reads are needed to service it. alternatively two smaller requests can proceed together. the buffering and pci interface will maintain the ordering of the reads. the request path and rdr buffer in the pci interface are shared with pio and dma requests, but there are dedicated return buffers for the peer-to-peer rdr. queue queue 1 write queue 1 read queue if reads queue 1 wr queue 2 rdr queue queue else 5 wr queue issue to queue pci bus up to 4 posted up to 4 non-posted 2 rd 1 rdr ht pci issue 1 peer-peer read for 32 byte req 2 peer-peer read for 64 byte req 1 rdr bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 222 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r pci a rbiter the device incorporates a pci bus arbiter that may be used when the interface is configured as the host bridge. the arbiter supports four external devices in addition to the host. arbitration is done using a single-ring round robin scheme with the bus parked on the last granted device when there are no new requests. except for the hotplug situation described below, the arbiter will wait for up to 32 pci clocks for the master to assert frame before removing the grant (the "broken" master case of section 3.4.1 of the pci specification), but requests from the master will continue to be responded to and the arbiter does not have a status register that records this being done. the arbiter includes support for hotplug systems. when the hotplug_en bit is set in the additional status and control register (at offset +88 in the pci confi guration registers) and p_req_l[3] is asserted, once p_gnt_l[3] is granted it will be held in the asserted (granted) state as long as p_req_l[3] is asserted, independent of higher priority requests. in addition to enabling hot plug systems, this can be used to solve some arbitration problems in some older southbridge devices. pci i nterrupts the pci interface includes 4 active low interrupt lines p_inta_l-p_intd_l. when used as a host the interface will normally use all of these as the interrupt inputs from the other pci devices (the pci specification describes the recommended way of permuting these as they are connected to the inta#-intd# pins of slots or devices). in all cases the four lines are monitored as active low interrupt inputs and the results presented to the interrupt mapper as sources 56-59 (see table 22: ?interrupt sources,? on page 52 ). any of the inputs that are not used by pci devices can therefore be used as general active low interrupt inputs. the p_inta_l signal can also be driven (as an open collector output) by the interface (note that when it is driven low the input logic will detect that it is low and raise system interrupt 56). this is intended for use in device mode to allow an interrupt to be driven to the host (see section: ?using the pci in device mode? on page 232 ). however, the output can still be driven when the interface is configured for host mode so a system that does not need four pci interrupt inputs may choose to use the p_intb_l-p_intd_l for pci use and use p_inta_l as a general open collector i/o. h yper t ransport d ifferences from r evision 0.17 s pecification this section lists the main differences between t he hypertransport specification revision 0.17 and the interface implemented in the bcm1250 and BCM1125h. since there was only limited distribution of the 0.17 specification, most readers will find the next section (differences from revision 1.03) more useful. 1 the transmitters drive unpredictable data on the cad and ctl lines during crc testing mode. 2 non-zero byte masks for double words which are not sent are ignored. 3 five additional error conditions are reported: protocol error detected on the link; receive fifo overflow error; response received with a srctag that has no corresponding request; end-of-chain nxa error issued to the link; and nxa error issued to a request from a peer host bridge (a request with a source tag of zero). 4 the interface has 4 responses to errors. localized errors result in an error response. the remaining errors can be set to result in sync flooding, raising the hypertransport fatal error interrupt or raising the hypertransport non-fatal error interrupt. 5 if the isochronous bit is set in a hypertransport request that is sent to the zbbus, it will have the l2 cache allocate bit set in the zbbus command. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 223 6 in a dual host topology, if any incoming packet, with an address mapped as to be forwarded to the outgoing link and a srcid = 0, is received by a host it will be nxaed. 7 the isa deadlock prevention mechanism, described in section c.1 of the hypertransport specification revision 0.17, is not supported. this mechanism has been removed in revision 1.0 of the specification. as a result, and as specified in revision 1.0, no peer-to-peer transactions involving isa are allowed. 8 the optional secondary bus reset functionality in the capability command register is implemented. 9 the interface only supports an 8 bit cad width. there is no support for the 2 or 4 bit widths that are described in revision 1.0. 10 the ordering between cpu (or any other internal device) writes to the hypertransport fabric and dma read data return to the hypertransport fabric is imposed in the hypertransport interface. this ordering is not part of the zbbus. in particular the i/o bridge and zbbus behave as if the response may pass posted writes bit is always set. if the pci producer-consumer model is being used read responses should always pass posted writes and this bit should always be clear. the result of not having the ordering rule internally is that if hypertransport device a polls a flag in memory that the cpu writes after writing hypertransport device b (which may or may not be the same device), the read response with the flag set may reach device a before the write reaches b. the ordering can be enforced by the cpu doing a pci or hypertransport configuration register read between the two writes. this forces the write to device b into the hypertransport interface (where the ordering rules apply) before the flag gets written in memory. (this also applies for the pci interface). 11 posted writes have the highest priority with regard to transmission to the hypertransport link. starvation of non-posted transactions and read responses is prevented by implementing counters in all entries of the interface transmit fifos. the outgoing entry counter s will get incremented on each transaction issued. when an entry?s counter overflows, its priority is elevated. 12 the correct ordering of interrupts with respect to writes from the hypertransport into the bcm1250 is maintained. an interrupt that follows a hypertransport write will not be raised inside the bcm1250 until the write is visible inside the zbbus coherency boundary. 13 a non-posted write from the hypertransport fabric to the zbbus or pci bus will be acknowledged when the write leaves the hypertransport interface, and will co ntinue as a posted write. error responses are never generated for non-posted writes. therefore, if the hypertransport device needs to confirm the success of a non-posted write, it must (1) wait for the write tgtdone response, then (2) issue a read to the write address for confirmation. it cannot issue the read without waiting for tgtdone since non-posted transactions may bypass each other. 14 no peer-to-peer i/o space traffic between the hypertransport and pci is supported. 15 no dma master is allowed on an isa bridge on the hypertransport or pci buses. it could result in a deadlock. 16 pci devices designed for rev2.0 or earlier may not be bridged off the hypertransport. 17 the linkfreq register, described in revision 1.0 of the specification, has been added to the hypertransport capability registers. this frequency set in this register sets both the transmitter frequency and the maximum frequency the receiver can accept. 18 support has been added for frequencies other than those specified in hypertransport revision 1.0 by using the sipfrequencydirect bit in the hypertransport sri command register. 19 in a dual hosted system determination of the master and slave ends of the chain must be made before link configuration. neither the hypertransport specificat ion nor the bcm1250 hardware specify the method for determining this. system designers are free to implement it in whatever way matches their system. three possible methods on the bcm1250 are: use one of the so ftware configuration bits latched into the system configuration register from the io_ad[31:26] during reset (see table15onpage43 ); store the information in the boot rom; store the information in a configuration eeprom on the smbus. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 224 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r h yper t ransport d ifferences from r evision 1.03 s pecification this section compares the hypertransport interface with the hypertransport i/o link protocol specification rev 1.03 10/10/2001. this is the first specification released by the hypertransport consortium, the specification details and section numbers match t he 1.02 release made by amd. comments are made by section number in the specification. (the sections were reordered in ht 1.04.) 1.1 terminology care is needed with the term doubleword. in hype rtransport/pci it is used for four bytes, in mips it is used for eight bytes. 2 signaling the interface only supports 8 bit links (8 cad pairs, 1 clk pair, 1 ctl pair). the optional power management signals are not supported. 3.2.1.4 command encoding the interface uses the isochronous bit in wr(sized) and rd(sized) inbound (dma) commands to set the zbbus l2ca flag to request the access be allocated in the l2 cache on a miss. all memory accesses will be marked cacheable coherent and all others uncached regardless of the coherence bit in the command. 4.1 topology the part is always a host. if the interface revision is 3 or greater the actasslave mode is supported for double-hosted chains. 4.1.1 double-hosted chains the interface supports double-hosted chains. designation of the master and slave end must be done by software. the host hide function is not implemented. the actasslave is implemented in interface revid 3 and greater, but is not available on earlier versions. care is therefore needed to understand the dataflows in sharing double-hosted chains. in a chain with two hosts a and b, if the mac or serial port dma engine on a is doing writes to any device through the hypertransport then accesses from b to any of the peripherals behind i/o bridge 1 on a can cause deadlock. 4.1.2.2 host implementations the interface has ldt_pwrok and ldt_reset _l separated from the system reset. a system reset will always cause the hypertransport to reset until released by software. see section: ?hypertransport resets? on page 259 for more details. 4.2 transactions and unitid the interface is a host and therefore always uses unitid 0. in interface revid 3 and greater the actasslave function allows the interface to use the unitid set in the devnum field on a double- hosted chain. 4.4.1 sized writes in byte writes nonzero byte masks are ignored for doublewords that are not sent. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 225 4.4.2 broadcast message the only broadcast message the interface will generate is an eoi. no broadcast messages are accepted. 4.4.3 flush, 4.4.4 fence the interface will never generate a flush or fence command. they will be accepted and flush will result in a tgtdone return. 4.4.5 atomic read-modify-write the atomic read-modify-write is neither generated nor accepted by the part. 4.5.2 target done target done is returned when a request has been sent from the hypertransport interface to the i/o bridge. inbound targetdone responses cause the target done counter to increment (making the completion visible to the processor). 4.7 virtual channels the three standard virtual channels are supported. since all writes within the part are posted, the only writes that will be in the non-posted channel are configuration space writes. 4.9.4 host bridges 1. the interface supports the optional double-hosted memory space region as described in section: ?accessing the sibyte from a sibyte on a double hosted chain? on page 212 . responses from the part always have the bridge bit set (rather than the specified clear) and a unitid of zero. 2. broadcasts are dropped. 3. directed requests are accepted as described in the section: ?accessing the sibyte from hypertransport devices? on page 210 . 4. this rule is not completely enforced. responses with the bridge bit set and a unitid of zero are treated as responses from a host on the far end of the link and compared to the outstanding requests. 5. a srctag error is logged in the hypertransport error status register ( table 153 ) if a responce is received with no matching request. 5 interrupts the interrupt usage follows the earlier hypertransport specification which has now been moved to the x86-specific appendix. 5.1 interrupt requests the intrinfo[55:32] bits are not supported. intrinfo[31:2] are interpreted in a similar way to the x86-specific model, as described in section: ?hypertransport interrupts? on page 48 . interrupt messages can be generated using the special address range described in section: ?hypertransport end of interrupt (eoi) signaling space? on page 198 . 5.2 end of interrupt the interface ignores any eoi messages it receives. eoi messages are generated by software as described in section: ?hypertransport end of interrupt (eoi) signaling space? on page 198 . bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 226 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 6.1 upstream i/o ordering the interface follows the ordering rules through the hypertransport interface into the i/o bridge. 6.2 host ordering rules the ordering rules are maintained into the zbbus domain, which has a different set of rules. the same ordering is used for cacheable and non-cacheable commands, and the rules for these, interrupt messages and responses are maintained correctly. however, because the zbbus allows responses to pass posted writes care must be taken when using the producer- consumer model as described in point 10 of the previous section. 6.2.1 host responses to nonposted requests a non-posted write is acknowledged as the transaction leaves the hypertransport interface and becomes a posted write internally. see point 13 of the previous section. 6.4 ordering in sharing double-hosted chains the i/o bridge and hypertransport interface will always push posted writes ahead of read responses. but this is not the case internally and care must be taken because the zbbus always allows read responses to pass posted writes. see the section: ?ordering rules and device drivers? on page 14 . 7.1 configuration cycle types configuration cycles are generated as described in section: ?configuration of pci and hypertransport? on page 234 . 7.3.1.1 i/o space enable, 7.3.1.2 memory space enable these bits are always set because the address decoders on the zbbus are always active. 7.3.8 interrupt line the interrupt line register is not writeable. 7.3.2.3, 7.3.2.4, 7.3.2.5 primary bus error status bits these bits are always clear because errors on the zbbus side are reported in other ways. 7.4.8.3 isa enable the optional isa address scrambling is not supported so this bit is always 0. 7.4.8.4 vga enable the optional vga address forwarding is supported so this bit is r/w. the implementation is described in section: ?the southbridge, vga and subtractive decode? on page 195 . 7.5 capability registers the interface uses the host format from the earlier hypertransport specifications, these cover the +00, +04 and +08 offsets of the block in table 29 of the hypertransport specification. interface revision 3 uses the format from the 1.03 specification. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 227 7.5.3.3 host interface command bits the pass 2 bcm1250 does not implement the fields that are new in the revision 1.02 specification: device number, chain side, host hide, act as slave, drop on uninit. interface revision 3 and greater, used for the BCM1125h and later versions of the bcm1250, includes these. the new host inbound end of chain error (bit 11) functionality is incorporated in the mapnxaerror bit in the hypertransport error status register ( table 153 on page 253 ). 7.5.4 link control register the interface does not implement the fields that are new in the revision 1.02 specification: isocronous enable, ldtstop# tristate enable, extended ctl time. none of the functionality that these control is supported. 7.5.5 link configuration register this register reflects the fact that the interface only supports 8 bit links and does not support doubleword flow control. 7.5.8 link error register the error conditions reported in this new register are reported in the hypertransport error status register ( table 153 on page 253 ). note that if the bridge is put into the direct frequency selection mode (allowing link frequencies outside the standard) then bit 4 is used for frequency selection. 7.5.9 link frequency capability the link frequency capability register is only supported on revision 3 and greater of the interface. on revision 2 (bcm1250 pass 2) it would have the value 16?h801f, indicating that frequencies up to 600mhz are supported and there are vendor specific frequencies. on revision 1 (bcm1250 pass 1) it would have the value 16?h800f, indicating that frequencies up to 500mhz are supported and there are vendor specific frequencies. 7.5.10 feature capability register the link feature capability register is only supported on revision 3 and greater of the interface. on older revisions it would have the value 16?h0004. 7.5.11 enumeration scratchpad this register is not implemented (its address collides with the sri registers). 7.5.12 error handling register the functions in this new register are available in the hypertransport error control register ( table 152 on page 252 ). 7.5.13, 7.5.14 memory base/limit upper bits these are not implemented since the interface constrains pci style memory operations to the low section of the address map, and has special rules for addresses above the 32-bit region. 7.6 interrupt discovery and conf iguration capability block this new capability block is not implemented. generation of interrupt messages is done by software, and is restricted to intrinfo[55:32]=0 and intrinfo[31:24]=f8 (i.e. compatibility with revision 1.01 and earlier and the x86 specific interrupt restrictions). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 228 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 7.7 address remapping capability block the interface does not have an address remapping block, the mappings between the zbbus and hypertransport addresses are discussed in the earlier sections of this chapter. 8 system management the interface does not support any of the legacy x86 system management or special cycles. the optional ldtstop# is not supported. 9 address map the internal address map ( table11onpage36 ) reflects the requirements of the hypertransport map. only interrupts with address[31:24]=f8 are accepted. 10.1 error conditions the interface detects and reports the errors described in this section. since the method of detection and reporting were not specified in earlier versions of the hypertransport specification the implementation differs. 10.1.1 transmission errors a crc error is detected and reported as in the specification. the sync flood control is in the link control register as specified. the interrupt enable bits are in the hypertransport error control register ( table 152 on page 252 ) rather than the new error handling register in the extended register set. when a crc error is detected the expected and received crc values are logged in the hypertransport diagnostic receive crc expected ( table 158 on page 254 ) and received ( table 159 on page 254 ) registers. 10.1.3 protocol errors, 10.1.4 receive buffer overflow errors protocol and overflow errors are reported in the hypertransport error status register ( table 153 on page 253 ) rather than the new link error register, and controlled in the hypertransport error control register ( table 152 on page 252 ) rather than the new error handling register in the extended register set. 10.1.5 end of chain errors the end of chain error is reported in the eocnxaerror flag in the hypertransport error status register ( table 153 on page 253 ) and controlled in the hypertransport error control register ( table 152 on page 252 ). the mapnxaerror flag is used to report two variants of the issue described in the spec as host inbound end of chain error. a mapnxaerror is flagged when a posted operation is received that is to an address that is not on the hypertransport link or pci and does not decode to a legal address within the bcm1250. it is also flagged and the transaction dropped, for a posted operation if the srcid is zero (i.e. it has come from the other host on a double-hosted chain) and the destination is an address on the hypertransport link. in this second case the transaction has already been rejected by all devices on the link, and sending it back will just lead to the transaction looping forever. 10.1.6 chain down errors the host interface discards all state on a link reset# and does not report a chain down error. responses for in-flight reads will be lost and the requestor may hang. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 229 10.1.7 response errors a response received without a matching source tag (or as a result of a response to a wrsized request) is reported as a srctagerror in the hypertransport error status register ( table 153 on page 253 ) and controlled in the hypertransport error control register ( table 152 on page 252 ). no check is done for a tgtdone response or an incorrect count received for a rdsized request, the requester will receive unpredictable data in this case. the interface does not generate flush or atomic read-modify-write cycles. 10.2.1 error responses error responses are controlled by the master abort mode bit as the specification describes. bit 5 of table 146 describes the method used to propageate errors from the hypertransport fabric to the zbbus. 10.2.2 error interrupts the error interrupts are passed directly to the interrupt mapper as interrupt numbers 48 and 49. 10.2.2 error routing csrs the error csr bits in the implementation are summarised in the table 125 on page 229 below which follows the format of the table 50 in the hypertransport specification. 11.1 clocking mode definition the interface supports synchronous and asynchronous mode. software must configure the interface before setting the sipready bit, as described in the ?system reset initialization of the hypertransport interface? on page 255 . 12 reset and initialization the interface performs the standard link initialization after software has configured the low level parameters and set the sipready bit. table 125: error routing registers error type log bit flood enable fatal error enable nonfatal error enable protocol errstat/protoerr errctrl/ protsyncflood errctrl/ protfatalen errctrl/ protnonfatalen overflow errstat/ovferr errctrl/ ovfsyncflood errctrl/ ovffatalen errctrl/ ovfnonfatalen eoc errstat/ eocnxaerr errctrl/ eocnxasyncflood errctrl/ eocnxafatalen errctrl/ eocnxanonfatalen inbound eoc (covers more than spec) errstat/ eocnxaerr errctrl/ eocnxasyncflood errctrl/ eocnxafatalen errctrl/ eocnxanonfatalen response errstat/ srctagerr errctrl/ srctagsyncflood errctrl/ srctagfatalen errctrl/ srctagnonfatalen crc linkctrl/ crcerr linkctrl/ crcflooden errctrl/ crcfatalen errctrl/ crcnonfatalen serr secstatus/ serrdet bridgectrl/ serren errctrl/ serrfatalen not supported bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 230 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 12.2 low level link initialization and table 54 values of ctl and cad during link initialization sequence the transmit side will generate 512 cycles with ctl and cad as zero before asserting cad and the receive side will accept 512+m cycles. this matches both the older versions of the spec which need 'a minimum of 512 cycles' and can have an arbitrary number of additional bit times, and the newer version '512+4n' where the minimum is still 512 cycles (n=0) but any additional duration of ctl and cad at zero must be for a multiple of four bit times. 12.3 i/o fabric initialization since the mips architecture does not support non-posted writes the tgtdone counter has been added to allow detection of the completion of configuration writes. in a double-hosted chain software is responsible for determing which is the master and slave ends of the fabric and performing appropriate configuration. 12.3.1 finding the firmware rom the part cannot boot from a rom over the hypertransport link. 12.5 link frequency initialization the interface will normally perform the link frequency change on a link reset, and revert to 200mhz on a cold reset. however, to support other devices that use the hypertransport specification from before revision 1.0 this behaviour can be prevented by setting the srildtpllcompat bit in the sri command register ( table 149 on page 251 ). a. address remapping the interface supports the host address map as outlined throughout this chapter, so does not need the address remapping scheme. b. ordering rules the hypertransport interface uses the pci ordering rules. c. mapping of other protocol ordering rules the interface maps from the zbbus as described in c.1. non-posted writes are not part of the mips architecture and so will never be generated for memory-mapped i/o. d. considerations for isochronous traffic the interface does not use the new isochronous scheme. the isochronous bit from dma read or write requests is copied into the l2ca flag for the zbbus transaction. isochronous requests will therefore cause l2 allocation on a miss. the part always generates requests with the isochronous bit clear. e.1, e.2 isa/lpc support there is no special isa/lpc support. all warnings and restrictions in these sections must be followed. note that pci devices that only support revison 2.0 or earlier of the pci specification may have similar problems to isa devices since they do not support the full ordering and transaction acceptance rules. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 231 e.3 subtractive decode subtractive decode is discussed in the ?the southbridge, vga and subtractive decode? on page 195 . f.1 interrupts the interface follows the x86 interrupt mechanism as outlined in section: ?hypertransport interrupts? on page 48 . interrupt messages and eoi are generated by software as described in section eoi signalling space on section: ?hypertransport end of interrupt (eoi) signaling space? on page 198 . in logical mode intrdest[31:2] bits are ignorred and the low two bits used to select the processor(s) that will receive the interrupt. the mt[3] bit is ignored so legacy pic nmi and extint get mapped on to the regular nmi and extint interrupts. g. crc testing mode the crc testing mode is supported. the data used during the test is unpredictable. h. doubleword based data buffer flow control the interface does not support the optional doubleword flow control. o rdering r ules the hypertransport fabric and the pci bus have a set of ordering rules described in appendix e of the pci specification revision 2.2. these differ from the mo re relaxed ordering rules used on the zbbus. the pci/ hypertransport rules are imposed in the i/o bridge which will allow posted writes to pass reads and will not allow read responses to pass posted writes, allowing the producer-consumer model to be used. using this model requires some care, see section: ?ordering rules and device drivers? on page 14 . a deadlock exists in the ordering boundary between the zbbus and i/o bridge 1 (in the hypertransport terms bridge 1 does not have sufficient virtual channels). this is only provoked when writes from i/o bridge 1 are targeted at the pci/ht space (the access must have come from one of the mac or serial dma engines) at the same time as any write is in progress from the pci/ht to any address serviced by bridge 1 (see figure 5 on page 9 for the devices that are serviced by bridge 1) or a read is in progress from i/o bridge 1 to bridge 0. this deadlock can be avoided by forbidding the bridge 0 to bridge 1 writes and the bridge 1 to bridge 0 reads. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 232 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r u sing the pci in d evice m ode the part can be used in pci device mode in a couple of different situations. the main one is when it is used as a pci device on an option card and the second is when the pci is used to connect several parts in a system. the bar0, bar2, bar3 and rom bar are active in device mode. most accesses by an external host will be done through bar0 and the mapping table, bar2 and bar3 will be used for the host to communicate with the sb-1 cpus via the mailbox registers and the rom bar will typically only be used during initialization. when the part needs to make a memory space access on the pci it will use the full access space, which allows any (32 bit) pci address to be generated, i/o accesses can be made through the normal i/o space range. in device mode the pci configuration is mostly done by the host in the system. however the bar0 map registers, the subsysset register (and the vendor idset and classrevset) and the inta control bit can only be set by configuration accesses from the zbbus side of the pci interface and are therefore under control of software on the device. the address map on the pci bus is different from the address map within the part, and translation is done through the bar0 address map. the map table allows c ontrol of what areas of the local memory map are accessible to an external pci master. therefore it is protected and can only be used with configuration accesses from the zbbus side of the bridge. configuration accesses to the map table registers will be accepted from the pci bus, but the writes will be ignored and reads will return unpredictable values. the external master will always see the bar0 region as a 16 mbyte space that needs an address allocation, software running on the part should configure the map table to allow access to appropriate internal resources. the peer- to-peer mappings in the map register give the device some of the characteristics of a non-transparent pci to hypertransport bridge. the subsysset register can only be written from the zbbus side of the bridge. it is used to provide a value in the subsystem device and vendor id registers seen by external configuration reads. in device mode software on the part should write the subsysset register with a value that identifies the manufacturer of the option card and its part number. this write must be done early in initialization, before the host needs to read the value. on interface revision 3 and greater the device/vendor id r egister and the class/rev register seen by external configuration reads can also be set using the vendoridset and classrevset registers. the inta control bit can be used by the device to signal a pci interrupt on the (bidirectional) p_inta_l pin. again, this bit can only be accessed from the zb bus side and external accesses have unpredictable results. the p_rst_l signal is only an output, and is therefore only appropriate for use when the part is in host mode. in device mode the pin is not used. there are two options for connecting the pci reset signal. when the part is used on an option card it should be reset when the pci bus is reset, therefore the pci reset should drive the reset_l input to the part. when the pci is used to connect multiple parts in a system they may need to be independently reset, in this case the pci reset line c an be connected to one of the gpio pins used as an interrupt input. software running on the device mode part can then read the state of the pci reset and can be interrupted to take appropriate action if the pci bus is unexpectedly reset during normal operation. accesses to the pci configuration registers in device mode are confused by their being shared between accesses from within the part (zbbus accesses) and accesses originating as type 0 configuration cycles on the pci bus (pci accesses). in addition the interface must ensure that the host doing pci accesses does not attempt to read the subsystem information before loca l software has written the subsysset register. the rd_host bit, in the write only device control register, is used to control the access. this bit is only used in device mode. it defaults to being set which allows read and write zbbus accesses to the static interface identification, the bar0 map entries, the subsysset register and the signalinta register. while the bit is set user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 233 any pci access will be issued with a retry. software on the part should do initial configuration of the map registers and set the subsystem information before writing a zero to the rd_host bit and flush the write to the interface by following it with a dummy read that will return unpredictable data. to be compliant with the pci specification this must be done within 1 second (0.55 on a 66 mhz bus) of the pci reset being deasserted. while the system is running with the rd_host bit clear zbbus writes may be done to the map entries and the signainta register. writes to the subsysset register will result in the subsystem id being updated, but the results of changing this after device enumeration is system specific: the subsystem information may never be read again or the operating system may assert an error because static information changes. reads to any of the pci configuration registers will return unpredictable data. the rd_host bit may be set to give read access to the map entries, subsysset and signalinta, but while the bit is set any read requests from the pci bus will be issued retries (read access will probably only be needed for debugging). table 131 summarizes access to the pci configuration registers. table 126: pci csr access rules register zbbus read zbbus write pci read pci write host mode device/vendor id ( 0 ) class/revision ( 8 ) valid data ignored unpredictable unpredictable map entries ( 44-80 ) subsysset ( 8c ) signalinta ( 90 ) valid data write register unpredictable unpredictable interface revision 3 or later vendoridset ( 9c ) classrevset ( a0 ) valid data write register unpredictable unpredictable others valid data write register unpredictable unpredictable device mode with rd_host = 1 device/vendor id ( 0 ) class/revision ( 8 ) valid data ignored retried unpredictable map entries ( 44-80 ) subsysset ( 8c ) signalinta ( 90 ) valid data write register retried ignored interface revision 3 or later vendoridset ( 9c ) classrevset ( a0 ) valid data write register retried ignored others unpredictable unpredictable retried unpredictable device mode with rd_host = 0 device/vendor id ( 0 ) class/revision ( 8 ) unpredictable unpredictable valid data ignored map entries ( 44-80 ) subsysset ( 8c ) signalinta ( 90 ) unpredictable write register unpredictable unpredictable interface revision 3 or later vendoridset ( 9c ) classrevset ( a0 ) unpredictable write register unpredictable unpredictable others unpredictable unpredictable valid data write register bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 234 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r c onfiguration of pci and h yper t ransport the pci bus and hypertransport fabric both require configuration before use. this is normally done by the startup firmware, but may also be done by the operating system as it starts. there is usually a "pci-bios" abstraction layer above the configuration hardware (this is only well specified for the x86 architecture, but most systems have a version of it). since hypertransport devices use the same configuration headers as pci, only minor changes to the configuration software will be needed to support it. in particular accesses to the pci/ hypertransport memory or i/o ranges are unpredictable until the hypertransport mem_base, mem_limit, io_base and io_limit registers have been programmed, and configuration accesses to anything other than bus 0 are unpredictable until the hy pertransport secondary and subordinate bus numbers have been programmed. (see section: ?systems that do not use hypertransport? on page 236 if hypertransport is not used.) during configuration the tree of bridged buses (an entire hypertransport chain is regarded as a single bus) is built along with a list of devices on each bus and their memory size requirements. the buses are allocated numbers, with bus 0 being at the root of the tree. a bridge gets configured with a bus number for its primary interface (the one that is closest to the root of the tree), a bus number for its secondary interface (the other bus it directly connects to) and a subordinate bus number which is the highest numbered bus that is behind the bridge (all buses in the range secondary - subordinate are accessible through the bridge). once all the buses are enumerated the configuration code will assign base addresses to all the devices. there are three separate address ranges: for memory mapped i/o, prefetchable memory, and i/o space. in each range, all addresses allocated behind a bridge must be contiguous. configuration uses the logical organization of the interfaces shown in figure 36 on page 191 . the pci bus on the part is bus 0 at the top of the configuration tree and therefore has its configuration space at bus 0, device 0. the hypertransport bridge configuration is at bus 0, device 1. (the bus number that will be given to the hypertransport fabric depends on the enumeration software). the configuration space for pci and hypertransport is based at 00_fe00_0000 for match bit lanes (the most useful endian policy for configuration) with a repeat at 00_de00_0000 using the match byte lane policy. to access a configuration register the address is formed from the register, function, device and bus number as shown in figure 49 . reads and writes of up to 32 bits can be done. the results of doing a 64 bit access to configuration space are undefined. note that in device mode the pci interface will mostly be configured by the host in the system, but the device mode part must still configure the bar0 address mapping table and the hypertransport fabric. figure 49: configur ation space address 0 0 fe bus number device number function number register number 39 32 31 24 23 16 11 10 8 7 15 2 0 1 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 235 accesses to the configuration range with bus 0 device 0 and bus 0 device 1 will be directed to the internal configuration registers for the pci and hypertransport interfaces. once the cpu has performed a series of writes to the internal configuration registers it should read back at least one. this will ensure the writes have taken effect before any other operations will proceed. although the transfers will be in order on the zbbus the data phase will be behind the address. if there is no read separating a configuration write from a subsequent transaction it is possible for the address of the trans action to reach the interface before the data of the configuration write, in this case the address decode for the transaction would be done based on the old value of the configuration register. other accesses to bus 0 devices will be sent as type 0 configuration cycles on the pci bus, the mapping used for generating idsel is to convert the device number into a single one on ad[31:11]. since the internal pci and hypertransport headers are device 0 and 1 the external devices start with ad[13] being set for device 2, ad[14] being set for device 3 and so on up to ad[31] being set for device 20 (note that the internal pci arbiter only supports four external devices). during pci configuration cycles the interface will pre-drive the address on the bus for a cycle (as described in section 3.2.2.3.5 of the pci specification revision 2.2), this allows a resistor to be used to connect to the idsel inputs of pci devices. a pci configuration read to a nonexistent device will be terminated with a master abort and set the status flags to indicate this happened, the data returned will be marked valid and will contain 32?hffff_ffff (for normal accesses, a master abort will result in a bus error return). when a pci configuration read is aborted in this way all other reads that are in flight in the pci bridge will be terminated with a bus error. software should therefore ensure that there are no reads in progress through the pci bridge when it is probing the pci bus for devices. note that configuration reads that encounter other pci errors (e.g. a parity error) will also return 32'hffff_ffff. if the bus number of an access to the configuration range matches the secondary bus number configured in the hypertransport bridge, the request will be forwarded as type 0 configuration accesses on the hypertransport fabric. this is done by turning it in to an access to the address range given in the hypertransport specification for configuration. ac cesses that have a bus number greater than the hypertransport bridge secondary bus and less than or equal to the hypertransport subordinate bus number are sent as type 1 configuration accesses on the hypertransport fabric. errors generated from configuration accesses to ht will be forwarded to the zbus rahter than the pci bridge. all other accesses are sent as type 1 configuration accesses on the pci bus. this is shown algorithmically in the pseudo-code below. endian = zbaddr[29] ? match bit lanes : match byte lanes bus = zbaddr[23:16] device = zbaddr[15:11] func = zbaddr[10:8] reg = zbaddr[7:0] if (bus == 0) { if (dev == 0) access pci config reg else if (dev == 1) access hypertransport config reg else do pci type 0 cycle (dev, func, reg) } else if (bus == ht secondary bus) { // form special ht type 0 config address htaddr = fd_fe00_0000 + zbaddr[15:0] do ht access } else if (ht secondary bus < bus <= ht subordinate bus) { // form special ht type 1 config address htaddr = fd_ff00_0000 + zbaddr[23:0] do ht access } else do pci type 1 cycle (bus, dev, func, reg) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 236 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r hypertransport target done counter since the mips architecture does not support non-posted writes it is hard for software to tell when hypertransport configuration writes have completed. to help with this a counter has been implemented in the hypertransport additional status register. this counte r can be cleared by software writing a zero and will increment every time a tgtdone message is returned from the fabric. thus software can clear the counter, do all the writes to configure a hypertransport device and then poll the counter until it reaches the number of writes performed. this will ensure the final write has been acknowledged by the device. s ystems t hat d o n ot u se h yper t ransport if a bcm1250 or BCM1125h system does not use the hypertransport interface the mem_base, mem_limit, io_base and io_limit registers of the ht bridge must still be programmed. this configures a shadow copy of these registers that is by default unpredictable. the mem_limit should be set to be lower in address than the mem_base. the io_base upper 16 bits (bits [15:0] of offset h30 in the hypertransport configuration header) should be set above the 24 bit range used by the i/o space, for example the register can be written with 32?h0000f200 (note that subsequent reads will show bits [15:12] as zero). for configuration accesses to buses other than bus 0 to work the hypertransport secondary and subordinate bus numbers should be written with zero. until these registers are programmed accesses to the pci memory or i/o space will have undefined results. c onfiguration h eader d escriptions the following sections describe the configuration headers used by the pci and hypertransport interfaces. the pci interface is bus=0, device=0, function=0 so the header can be accessed from within the part starting at the base address is 00_fe00_0000 (match bits) or 00_de00_0000 (match bytes). the hypertransport interface is bus=0, device=1, function=0, with base address 00_fe00_0800 (match bits) or 00_de00_0800 (match bytes). the following terms are used in the register descriptions: r/o. read only. the field contains a static value and should not be written. r/w. read/write. the field can be modified by software. r/c. read/clear. the field can be read to give status information. bits may be cleared by writing a 1 to them, writes of 0 are ignored. pci c onfiguration h eader the pci configuration header is a standard type 0 header with extensions to support the address map table. the following table shows the fields of the header, along with the values they contain after a system reset. table 127: pci interface configuration header (type 0) offset register bits description 31 24 23 16 15 8 70 00 device id r/o 0001 vendor id r/o 166d identifies the device as a broadcom sibyte family pci interface. 04 status (see table 129 on page 239 ) r/w 02a0 command (see table 128 on page 239 ) r/w 0002 as defined by pci standard. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 237 08 class code r/o 060000 rev id r/o xx class is a host bridge, revision reflects the interface revision code. the revision code is: 1 - for early prototype bcm1250s. 2 - for initial production bcm1250s 3 - for intial production BCM1125/h and later bcm1250s 0c bist r/o 00 hdr type r/o 00 lattimer ( ta b l e 1 3 0 o n page 240 ) r/w 00 clinesz ( table 131 on page 240 ) r/w 00 the bridge uses a type 0 device header. 10 bar 0 - map table host: r/o 6000_0008 dev: r/w xx00_0008 hits to this 16 mb bar will be translated through the mapping table. bit 3 is set to indicate a prefetchable region. 14 bar 1 - reserved r/o 00000000 this bar is reserved and will always be read as zero 18 bar 2 - mbox 0 host: r/o 7000_0008 dev: r/w xxxx_x008 hits to this 4 kb bar are translated into accesses to the mailbox set and value register for cpu0. 1c bar 3 - mbox 1 host: r/o 7100_0008 dev: r/w xxxx_x008 hits to this 4 kb bar are translated into accesses to the mailbox set and value register for cpu1. 20 bar 4 - low memory host:r/o 0000_0008 dev: r/o 0000_0008 (reserved) hits to this bar are passed through as accesses to the low 512mb of memory. 24 bar 5 - high memory host:r/o 8000_0008 dev: r/o 0000_0008 (reserved) hits to this bar are passed through as accesses to the upper 2gb of the low 4gb of the address space. 28 cardbus cis r/o 00000000 this register is not used. 2c subsystem id r/o 0000 subsys vendor r/o ffff these registers are not used internally since this is a host bridge. if the configuration registers are read by an external pci master with the bridge in device mode the value read from this register will be the value written from the zbbus to the subsysset register (offset 8c). 30 rom base address host: r/w 73000000 dev: r/w xxxx0000 hits to this 64 kb bar are translated to accesses to the boot rom area of memory. 34 reserved r/o 000000 cap ptr r/o 00 this register is not used. 38 reserved r/o 00000000 this register is not used. 3c max_lat r/o 00 min_gnt r/o 00 int pin r/o 01 int line r/w 00 the max latency and min grant registers are used to specify the device preferences for the latency timer, they default to indicate no special requirement. the intpin register indicates that this device uses inta to interrupt in device mode. the intline register is used by firmware and system software. 40 fcontrol (see table 133 on page 241 ) r/w 0003 timeout (see table 132 on page 240 ) r/w 8080 this additional register allows configuration of the retry and trdy timeouts and enable bits for special features. table 127: pci interface configuration header (type 0) (cont.) offset register bits description 31 24 23 16 15 8 70 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 238 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 44-80 map entry base address r/w 000000 flags r/w 00 the address mapping table for bar0, described in table 134 on page 241 . 84 error address r/o xxxxxxxx this register records the address of every transaction on the pci bus. when any of the error bits in the status register are set the address in this register is locked, recording the address of the transaction that experienced the error. the register is unlocked when software clears the error status. 88 additional status and command (see table 135 on page 241 ) r/w 00000000 this register contains addition command and status bits. 8c subsysset r/w 00000000 this register is only accessible from the zbbus. when the interface is configured in device mode the value written to this register from the zbbus will be read by an external read of register 2c. 90 signalinta r/w 00000000 bits 31:1 are r/o 0. bit 0 can be set from the zbbus to assert the inta pin. writing this bit from the pci has unpredictable results. 94 readhost w/o 00000001 this register controls register accesses in device mode. see table 137 on page 242 and ?using the pci in device mode? on page 232 98 adaptive extend r/w xxxxxx00 this register controls performance features. see table 138 on page 242 . 9c vendoridset r/w 0001166d this register is only available if the interface rev id is 3 or greater. this register is only accessible from the zbbus. when the interface is configured in device mode the value written to this register from the zbbus will be read by an external read of register 0. a0 classrevset r/w 06000003 this register is only available if the interface rev id is 3 or greater. this register is only accessible from the zbbus. when the interface is configured in device mode the value written to this register from the zbbus will be read by an external read of register 4. a4 bypassctrl r/w 00000fff this register is only available if the interface rev id is 3 or greater. this register controls the number of times a zbbus initiated write can pass a retrying read before the read is discarded and a fatal error signalled. a8-fc reserved reserved, accesses will have unpredictable results. table 127: pci interface configuration header (type 0) (cont.) offset register bits description 31 24 23 16 15 8 70 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 239 table 128: pci command register - offset 4 bits [15:0] bits name default description 0 iospaceen r/o 1?b0 i/o space enable. this bit is always zero. the bridge never accepts i/o space accesses from the pci bus. 1 memspaceen r/w 1?b1 revid>=3 r/w 1?b0 memory space enable. this bit must be set to allow the bridge to accept memory space accesses from the pci bus and forward them to either zbbus or the hypertransport bridge. in interface revisions 1 and 2 this bit defaults to 1 to enable these accesses after reset, in interface revision 3 and greater this bit defaults to 0 to match the pci specification. 2 masteren r/w 1?b0 bus master enable. this bit must be set to allow the bridge to act as a master on the pci bus. this bit should be set before any pci accesses are made. any accesses to the pci space that are received while this bit is clear will result in undefined behavior in the interface. 3 speccycen r/o 1?b0 the bridge does not accept special cycles, so this bit is always zero. 4 memwrinven r/w 1?b0 this bit should be set to allow the bridge to generate memory write and invalidate commands. the bridge will only use write invalidate if the start address is cacheline aligned and the transfer is at least one cache line long (using the cache line size set in the clinesz register). if the latency timer expires while a write invalidate command is in progress the access will only be terminated at the next cache line boundary. 5 vgapalsnpen r/o 1?b0 this bit is always zero. the bridge does not snoop vga palette accesses. 6 parerrresp r/w 1?b0 this bit controls the response to pci parity errors. if it is set then the mstrdparerr bit is set in the status register and the pci error interrupt is raised when a parity error is detected. if it is clear then no interrupt is raised. in both cases the detparerr bit is set in the status register. a parity error resulting from a read will return data to the zbbus with a bus error if this bit is set, and returned as valid data if this bit is clear. 7 stepctrl r/o 1?b0 this bit is always clear. the bridge does not do address/data stepping. 8 serren r/w 1?b0 serr enable. if this bit is set, the bridge will drive the serr_l pin if it detects a fatal error. if clear the bridge will never drive serr_l. 9 fastb2ben r/o 1?b0 this bit is always clear. the bridge will never do fast back-to-back cycles to different devices. 15:10 reserved r/o 6?b0 reserved table 129: pci status register - offset 4 bits [31:16] bits name default description 3:0 reserved r/o 4?b0 reserved 4 caplist r/o 1?b0 always clear. there is no capabilities list. 5 66mhzcap r/o 1?b1 this bit is set. the pci is 66 mhz capable. 6 reserved r/o 1?b0 reserved 7 fastb2bcap r/o 1?b1 this bit indicates that the bridge can accept fast back-to-back transactions when the transactions are to different agents. 8 mstrdparerr r/c 1?b0 this bit is set if the bridge was a bus master and detected a parity error on read data, or was signalled that a parity error happened on write data. the parerren bit in the command register must be set to allow this bit to be set. if this bit is set the pci error interrupt is asserted. it is cleared by software writing a 1. 10:9 devseltiming r/o 2?b01 the bridge generates medium devsel timing. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 240 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 11 sigdtgtabort r/c 0?b0 this bit is set when the bridge is the target of a pci transaction and signalled a target abort. if this bit is set the pci error interrupt is asserted. it is cleared by software writing a 1. 12 rcvdtgtabort r/c 1?b0 this bit is set when the bridge was a master for a transaction and received a target abort. if this bit is set the pci error interrupt is asserted. it is cleared by software writing a 1. 13 rcvdmstrabort r/c 1?b0 this bit is set when the bridge was a master for a transaction that was not a special cycle and signalled a master abort. if this bit is set the pci error interrupt is asserted. it is cleared by software writing a 1. 14 sigdserr r/c 1?b0 this bit is set when the bridge asserts serr_l. it will do this when it detects a parity error on an address. if this bit is set the pci error interrupt is asserted. it is cleared by software writing a 1. 15 detparerr r/c 1?b0 this bit will be set whenever the bridge detects a parity error, even if parity error handling is disabled. the parity error is only signalled using the pci interrupt if the parerrresp bit is set in the command register. this bit is cleared by software writing a 1. table 129: pci status register - offset 4 bits [31:16] (cont.) bits name default description table 130: pci latency timer - offset 0c bits [15:8] bits name default description 7:0 lattime r/w 8?b0 this contains the value of the latency timer for the bridge to use when bus master. if this register is left at its default value of zero the bridge will never do bursts on the pci. bits 1:0 are r/o and are always zero. table 131: pci cache line size - offset 0c bits [7:0] bits name default description 7:0 clinesz r/w 8?h0 this register sets the cache line size in dwords (32 bit words) used by the bridge for pci transactions. as a master the bridge bases the pci command used on how the size of the transfer matches the value in this register: word_count < one cacheline: use read command word_count >= one cacheline: use read line command word_count >= two cache lines: use read multiple command. this size is also used to enable the write invalidate command. table 132: pci timeout register - offset 40 bits [15:0] bits name default description 7:0 trdytimeout r/w 8?h80 this field sets the maximum number of pci cycles that the bridge will wait for trdy to be asserted. if trdy is deasserted for longer than this the transfer will be aborted. when a transfer is aborted the trdyerr bit is set in the additional status register and the pci_interrupt may be raised. if a read is aborted unpredictable data is returned to the zbbus marked with a bus error. 15:8 retrytimeout r/w 8?h80 this field sets the number of times a read will be retried following a disconnect. the read is first attempted this number of times. the bridge will then allow any outstanding writes and read-data-returns to proceed before retrying the read. in interface revisions less than 3 a second attempt is made, in revisions 3 and later the read is retried the number of times specified in the num_piowr_bypass field of the pci bypass control register ( table 139 ). if the read fails on the final attempt the transfer is aborted, unpredictable data marked with a bus error is returned to the zbbus and the retryerr bit is set in the additional status register. a write that is retried will be attempted the number of times specified in this field before being discarded and the retryerr bit set. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 241 each map table entry contains the mapping address and flags. there are 16 entries in the table, and it is indexed by bits [23:20] of the pci address. table 133: pci feature control register - offset 40 bits [31:16] bits name default description 0 bar4_en r/w 1?b1 this bit must be set to enable accesses through bar 4 in host mode. (default enabled). 1 bar5_en r/w 1?b1 this bit must be set to enable accesses through bar 5 in host mode. (default enabled). 2 ptp_en r/w 1?b0 this bit must be set to enable pci-hypertransport peer-to-peer transfers (default disabled). 3 adapt_retry_en r/w 1?b0 this bit must be set to enable the adaptive retry (see section: ?pci adaptive retry? on page 217 ) 6:4 min_tar_retry r/w 3?b011 sets the minimum number of cycles before a retry is issued when the adaptive retry algorithm is used. 10:7 nom_tar_retry r/w 4?b1011 along with the upper bits from the pci adaptive extend register this sets the nominal number of cycles before a retry is issued when the adaptive retry algorithm is used. 15:11 max_tar_retry r/w 5?b01111 along with the upper bits from the pci adaptive extend register this sets the maximum number of cycles before a retry is issued when the adaptive retry algorithm is used. table 134: pci bar0 map table entry - offset 44 ? 80 bits name default description 0 enable 1'b0 this bit must be set to enable the mapping. if it is clear the pci interface will not assert devsel# to accept the request. 1 send_ldt 1'b0 if this bit is set then the request will be forwarded to the hypertransport fabric (regardless of what the address is). if this bit is clear the request is sent into the bcm1250. 2 l2ca 1'b0 if this bit is set then the l2ca flag will be set when an access is made to the zbbus through this entry. this requests that the cache block be allocated in the l2 cache. 3 endian 1'b0 if the system is configured for big endian operation and this bit is set the match bits policy will be used, if this bit is clear the match bytes policy is used. if the system is configured little endian this bit is ignored. 11:4 reserved 8'b0 reserved 31:12 addr 20'b0 these bits provide bits 39:20 of the internal address. bits 19:0 are copied from the pci address. table 135: pci additional status and control register - offset 88 bits [31:0] bits name default description 0 hotplug_en r/w 1?b0 if this bit is set the hotplug function in the internal pci arbiter is enabled. 1 serr_det r/c 1?b0 set when some other device on the pci bus asserts serr (a pci error interrupt is also raised). software must write a 1 to this bit to clear it and remove the interrupt. 2 trdyerr r/c 1?b0 set when a transfer is aborted because trdy was not asserted within the trdytimeout (see table 132 on page 240 ). the trdyinten bit must be set in order for this bit to be set. software must write a 1 to this bit to clear it and remove the interrupt. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 242 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 3 retryerr r/c 1?b0 set when a transfer is aborted because a read was retried more than the retrytimeout (see table 132 on page 240 ). the retryinten bit must be set in order for this bit to be set. software must write a 1 to this bit to clear it and remove the interrupt. 4 trdyinten r/w 1?b0 if this bit is set the pci error interrupt will be raised and the trdyerr bit set on a trdy timeout. if this bit is clear no interrupt will be raised and the trdyerr bit will not be set. 5 retryintmask r/w 1?b0 if this bit is set the pci error interrupt will be raised and the retryerr bit set on a retry timeout. if this bit is clear no interrupt will be raised and the retryerr bit will not be set. 6 dismulti r/w 1?b0 this bit should be clear for normal operation. 31:7 reserved r/0 25?b0 reserved table 135: pci additional status and control register - offset 88 bits [31:0] (cont.) bits name default description table 136: pci inta control register - offset 90 bits [31:0] bits name default description 0 signalinta r/w 1?b0 if this bit is set the p_inta_l line will be asserted. this is intended for use in device mode when the device needs to interrupt the host. note that the input from p_inta_l is still active, so setting the bit will raise a pci inta interrupt to the interrupt mapper. this register should only be accessed from the zbbus side of the pci interface. writing to this register from the pci interface will have unpredictable results. 31:1 reserved r/0 31?b0 reserved table 137: pci read host register - offset 94 bits [31:0] bits name default description 0 rd_host w/o 1'b1 this bit controls cpu read access to the pci configuration registers when the interface is in device mode. by default this bit is set, allowing read access to the static pci registers, the bar0 map, the subsysset and signalinta regist ers. while this bit is set any read requests from the pci bus will be issued a retry. when this bit is clear the cpu can still write the registers but reads will return unpredictable data. 31:1 reserved w/o 31'b0 reserved table 138: pci adaptive extend register - offset 98 bits [31:0] bits name default description 0 reserved 1'b0 reserved 3:1 nom_tar_retry_h r/w 3'b0 this field is the top three bits of the nom_tar_retry value used by the adaptive retry algorithm. (see table 133 pci feature control register bits 10:7) 5:4 max_tar_retry_h r/w 2'b0 this field is the top two bits of the max_tar_retry value used by the adaptive retry algorithm. (see table 133 pci feature control register bits 15:11) 6 dis_dmar_iow_dep 1'b0 this bit should be zero for normal operation. if set no checking is performed for dependencies between dma read data return and pio writes. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 243 in host mode the header should be configured by the local processor (in many cases the default values will be reasonable and only the map table will need to be initialized), in device mode it will be configured by the external host. the map table allows control of what areas of the in ternal memory map are accessible to an external pci master. therefore it is protected and can only be used wi th configuration accesses from the zbbus side of the bridge. configuration accesses to the map table registers will be accepted from the pci bus, but the writes will be ignored and reads will return unpredictable values. when the interface is run in device mode, the external master will always see the bar0 region as a 16 mbyte space that needs an address allocation, software running on the device should configure the map table to allow access to appropriate internal resources. the peer-to-peer mappings in the map register give the part some of the characteristics of a non- transparent pci to hypertransport bridge. the subsysset register can only be written from the zbbus side of the bridge. it is used to provide a value in the subsystem device and vendor id registers seen by external configuration reads. in device mode software on the device should write the subsysset register with a value that identifies the manufacturer of the option card and its part number. this write must be done early in initialization, before the host needs to read the value. on interface revision 3 and later the device/vendor id and the class code that will be read by the external host can also be changed by using the vendoridset and classrevset registers. 7 dis_memrd_be 1'b0 this bit should be zero for normal operation. if set the byte enables will always be all set for read transactions. 8 prefetch_en r/w 1?b0 interface revision 3 or greater: this bit may be set to enable read prefetching to improve performance of block reads from the zbbus to the pci. 9 prefetch_sz r/w 1?b0 interface revision 3 or greater: if this bit is 0 two cachelines are prefetched when the prefetch_en bit is set, if it is 1 then 4 cachelines are prefetched. 31:10 notimp 22b'x not implemented. table 138: pci adaptive extend register - offset 98 bits [31:0] (cont.) bits name default description table 139: pci bypass control register - revid >= 3 offset a8 bits [31:0] bits name default description 11:0 num_pior_byp r/w 12?hfff a zbbus or ht-to-pci initiated read will be retried a total of num_pior_byp multiplied by the retry_timeout (in the timeout register). each retry_timeout there is a chance for one write to bypass the read (this is a workaround for older devices that did not correctly implement the pci ordering rules). 31:12 notimp 20b'x not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 244 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r h yper t ransport c onfiguration h eader the hypertransport configuration header is a standard pci type 1 (bridge) header, as defined in the pci-to- pci bridge architecture specification revision 1.1, with the extensions required by the hypertransport specification and device specific control extensions. the following table shows the fields of the header, along with the values they contain after a system reset. values marked r/o are read only. table 140: hypertransport configuration header (type 1) offset register bits description 31 24 23 16 15 8 7 0 00 device id r/o 0002 vendor id r/o 166d identifies the device as a broadcom sibyte family 8 bit hypertransport interface. 04 status (see table 142 on page 247 ) r/w 0010 command (see table 141 on page 246 ) r/w 0003 as defined in the hypertransport specification. 08 class code r/o 060000 rev id r/o xx class is a host bridge. the revision code is: 1 - for early prototype bcm1250s. 2 - for initial production bcm1250s 3 - for intial production BCM1125h and later bcm1250s 0c bist r/o 00 hdr type r/o 01 lattimer r/o 00 clinesz r/o 00 this is a bridge header. as defined in the hypertransport specification. 10 bar 0 r/o 00000000 not used. 14 bar 1 r/o 00000000 not used. 18 seclattimer r/o 00 subord bus# r/w 00 sec bus# r/w 00 pri bus# r/o 00 primary bus is fixed in hardware as 0. secondary and subordinate buses must be set by the pci/hypertransport bus enumeration code. 1c sec status (see table 143 on page 247 ) r/c 0000 i/o limit r/w x1 i/o base r/w x1 the low 4 bits of the base and limit registers indicate 32 bit i/o addressing and register 30 is used. the upper four bits are used to specify bits [15:12] of the base and limit of the range of i/o addresses that should be sent on the hypertransport fabric. this sets the address of region j in figure 37 on page 193 . 20 mem limit r/w xxx0 mem base r/w xxx0 the low four bits of the base and limit registers are always zero. the upper 12 bits specify address bits [31:20] of the base and limit of the range of memory addresses that should be sent on the hypertransport fabric. this sets the address of region b in figure 37 on page 193 . if the limit address is set lower than the base address then region b is disabled. 24 prefetch limit r/o 0000 prefetch base r/o 0000 these registers read as zero, since no special prefetchable memory region is supported. 28 prefetch base upper 32 bits r/o 00000000 2c prefetch limit upper 32 bits r/o 00000000 30 i/o limit upper 16 bits r/w 0xxx i/o base upper 16 bits r/w 0xxx the upper seven bits of the base and limit are fixed at zero. the lower nine bits are used to specify bits [24:16] of the base and limit of the range of i/o addresses that should be sent on the hypertransport fabric. this sets the address of region j in figure 37 on page 193 . user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 245 34 reserved r/o 000000 cap ptr r/o 40 points to hypertransport capability registers. 38 rom base address r/o 0 the hypertransport bridge does not support an expansion rom. 3c bridge ctrl (see table 144 on page 248 ) r/w 0000 int pin r/o 0 int line r/o 0 revid >= 3 r/w 0 the hypertransport does not use the interrupt registers, they always read as zero. on interface revision 3 and later the int line register is r/w but unused by the hardware as recommended by the ht specification. 40 htcmd (see table 145 on page 248 ) r/w 2001 cap ptr r/o 00 cap id r/o 08 this is the hypertransport capability block, there are no further blocks. 44 linkconfig (see table 147 on page 250 ) r/o 0000 linkctrl (see table 146 on page 249 ) r/w 0000 as defined in the hypertransport specification. 48 reserved r/o 0000 revid >=3 linkfreqcap r/o 801f ldt freq ( table 148 on page 250 ) r/w 00 ldt rev id r/o 11 revid >=3 r/o 23 interface revid 1 and 2 is based on hypertransport revision 0.17. interface revision 3 is based on hypertransport revision 1.03. the linkfreqcap indicates operation at 200-600mhz and vendor specific frequencies. 4c reserved r/o unpredictable r/o 0000 reserved r/o unpredictable revid >=3 features r/o 0004 reserved on revid 1 and 2. on revision 3 and later, this is the feature register indicating support for crc test and not other features. 50 sricmd (see table 149 on page 251 ) r/w 0000 srirxden r/w 10 sritxden r/w 10 system reset initialization registers. these registers must be configured by the cpu before the hypertransport fabric comes out of reset. the interface will assert the ldt_reset_l signal until the sipready bit in the sricmd register is set to indicate that these registers have been programmed. 54 sritxnumerator r/w 0000ffff 58 srirxnumerator r/w 0000ffff 5c reserved r/o unpredictable revid >=3 isocbar r/w 00000000 reserved on revid 1 and 2. on revid 3 and later, the isocbar and isocignmask selects an address range that inbound transactions will be allocated in the l2 cache. see section: ?force isochronous mode address range? on page 212 60 reserved r/o unpredictable revid >=3 isocignmask r/w 00000000 64 reserved r/o unpredictable reserved 68 errstatus ( table 153 o n page 253 ) r/c 00 errctrl (see table 152 on page 252 ) r/w 000000 error control and status register. provides additional control over interface error reporting. 6c reserved r/o 00 txctrl (see table 154 on page 253 ) r/w 04 databufaloc ( table 155 on page 253 ) r/w 1515 control registers. table 140: hypertransport configuration header (type 1) (cont.) offset register bits description 31 24 23 16 15 8 7 0 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 246 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 70-c4 reserved r/o unpredictable reserved c8 txbufcountmax (see table 157 on page 254 ) r/w 00ffffff transmit buffer control register. cc-d8 reserved r/o unpredictable reserved dc diagrxcrce (see table 158 on page 254 ) r/o xxxxxxxx expected crc (diagnostic register). e0-ec reserved r/o unpredictable reserved f0 diagrxcrcr (see table 159 on page 254 ) r/o xxxxxxxx received crc (diagnostic register). f4-fc reserved r/o unpredictable reserved table 140: hypertransport configuration header (type 1) (cont.) offset register bits description 31 24 23 16 15 8 7 0 table 141: hypertransport bridge command register - offset 4 bits [15:0] bits name default description 0 iospaceen r/o 1?b1 i/o space enable. this bit is always set. the hypertransport bridge always forwards i/o space transactions that originate on the zbbus and match the bridge i/o range. peer-to-peer i/o is not supported between pci and hypertransport. 1 memspaceen r/o 1?b1 memory space enable. this bit is always set. the hypertransport bridge always forwards memory space transactions that originate on the zbbus and match the bridge memory range. peer-to-peer transfers from the pci bus will always be accepted by the hypertransport bridge, but they can be disabled in the pci bridge by clearing the ptp_en bit in the pci feature control register (see table 133 on page 241 ). 2 masteren r/w 1?b0 primary bus (i.e. zbbus) master enable. this bit controls acceptance of requests from the hypertransport fabric. if a request has unitid=0 and contains an address that should be sent back on the hypertransport fabric (a peer-to-peer operation) it must have come the whole length of the fabric from another host bridge and it will always be responded to with an nxa error. 0: accept only configuration cycles and requests that must be sent back out on the hypertransport fabric. all other posted requests are dropped and non-posted requests return an nxa error. 1: accept all requests that match an address range in this part. 3 speccycen r/o 1?b0 these bits apply to pci bridges only. for a hypertransport bridge they are read only and always return zero. 4 memwrinven r/o 1?b0 5 vgapalsnpen r/o 1?b0 6 parerrresp r/o 1?b0 7 waitcycctrl r/o 1?b0 8 serren r/w 1?b0 serr enable. this controls the serr on the primary interface. since the zbbus has no equivalent of serr the setting of this bit is ignored. 9 fastb2ben r/o 1?b0 these bits apply to pci bridges only. for a hypertransport bridge they are read only and always return zero. 15:10 reserved r/o 6?b0 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 247 table 142: hypertransport bridge primary (zbb us) status register - offset 4 bits [31:16] bits name default description 3:0 reserved r/o 4?b0 reserved 4 caplist r/o 1?b1 always set. there is a capabilities list pointed to by the pointer register. 5 66mhzcap r/o 1?b0 these bits apply to pci bridges only. this register is the primary interface status register and contains the details for the zbbus side of the bridge. these bits always return zero. 6 reserved r/o 1?b0 7 fastb2bcap r/o 1?b0 8 mstrdparerr r/o 1?b0 10:9 devseltiming r/o 2?b0 11 sigdtgtabort r/c 0?b0 this bit is set when the hypertransport interface returns an error to the zbbus. it is cleared when written with a 1. note that an error code sent with the data is the zbbus equivalent of a target abort. 12 rcvdtgtabort r/o 1?b0 always clear. errors from the zbbus are logged by the bus watcher in the scd and errors from peer-to-peer pci accesses are logged in the pci bridge. 13 rcvdmstrabort r/o 1?b0 14 sigdserr r/o 1?b0 the interface does not directly signal serr on the zbbus interface, so this bit always returns zero. if a sync packet is seen on the hypertransport interface it will not be forwarded but it will be reported in the detserr bit in the secondary status register. 15 detparerr r/o 1?b0 always clear. errors from the zbbus are logged by the bus watcher in the scd. table 143: hypertransport bridge secondary (ht) status register - offset 1c bits [31:16] bit name default description 4:0 reserved r/o 5?b0 these bits apply to pci bridges only. for a hypertransport bridge they are read only and always return zero. 5 66mhzcap r/o 1?b0 6 reserved r/o 1?b0 7 fastb2bcap r/o 1?b0 8 mstdparerr r/o 1?b0 10:9 devseltiming r/o 2?b0 11 sigdtgtabort r/c 1?b0 this bit is set when the bridge issues a non-nxa error response on the hypertransport fabric. it is cleared when written with a 1. this bit is persistent through a warm reset. 12 rcvdtgtabort r/c 1?b0 this bit is set when the bridge receives a non-nxa error response from the hypertransport fabric. it is cleared when written with a 1. this bit is persistent through a warm reset. 13 rcvdmstrabort r/c 1?b0 this bit is set when the bridge receives an nxa error response from the hypertransport fabric. it is cleared when written with a 1. this bit is persistent through a warm reset. 14 detserr r/c 1?b0 this bit is set when the bridge detects sync packet flooding of the hypertransport fabric. it is cleared when written with a 1. this bit is persistent through a warm reset. 15 detparerr r/o 5?b0 this bit applies to pci bridges only. for a hypertransport bridge it is read-only and always returns a zero. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 248 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r table 144: hypertransport bridge control register - offset 3c bits [31:16] bits name default description 0 parerrrespen r/o 1?b0 this bit applies to pci bridges only. for a hypertransport bridge it is read only and always returns a zero. 1 serren r/w 1?b0 this bit must be set to enable detection of sync flooding on the hypertransport link. 2 isaen r/o 1?b0 this bit is always zero. the hypertransport bridge does not support modified isa address forwarding. 3 vgaen r/w 1?b0 this bit controls the routing of vga address accesses in the compatibility spaces ( 0a_0000 - 0b_ffff in memory space and x3b0 - x3bb and x3c0 - x3df in i/o space). if this bit is clear these addresses are sent to the pci interface and if set they are sent (without the compat bit set) to the hypertransport fabric. 4 reserved r/o 1?b0 reserved 5 mstrabortmode r/w 1?b0 error response behavior. this bit determines the way errors are forwarded through the hypertransport bridge. if this bit is set: any zbbus error causes a hypertransport error response with the nxa bit clear. any hypertransport error causes a zbbus bus error. if this bit is clear: any zbbus bus error or fatal error causes a valid hypertransport response. any other zbbus error causes a hypertransport error response with the nxa bit clear. any hypertransport error with the nxa bit set causes a zbbus response with valid data that is all ones. any hypertransport error with the nxa bit clear causes a zbbus bus error response. 6 secbusreset r/w 1?b0 if this bit is set the ldt_reset_l signal is asserted. if the warmreset bit in the hypertransport host interface command register is clear, the ldt_pwrok signal is deasserted to cause a cold reset. when this bit is set, clearing it will bring the fabric out of reset. 7 fastb2ben r/o 1?b0 these bits apply to pci bridges only. for a hypertransport bridge they are read only and always return zero. 8 pridiscard r/o 1?b0 9 secdiscard r/o 1?b0 10 discardstat r/o 1?b0 11 discardserren r/o 1?b0 15:12 reserved r/o 4?b0 reserved table 145: hypertransport command register - offset 40 bits [31:16] bits name default description 0 warmreset r/w 1?b1 if this bit is set then a warm reset of the fabric is done when the secbusreset bit is set in the bridge control register. if this bit is clear a cold reset is done. changing the state of this bit when the secbusreset bit is asserted results in undefined behavior. 1 doubleended r/w 1?b0 this bit is set by the master host bridge on other side of the chain to indicate that the slave host bridge is successfully configured on a double ended link. this bit is just used by software, it has no affect on hardware. 6:2 reserved revid>=3 devnum r/o 5?b0 r/w 5?b0 on interface revid 1 and 2 this field is reserved. on interface with revid 3 and greater this field is used to set the unit id the part will use if the actasslave bit is set. the default is restored on a cold reset. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 249 7reserved revid>=3 chainside r/o 1?b0 r/w 1?bx on interface revid 1 and 2 this field is reserved. on interface with revid 3 and greater this bit reads as a 0 from the zbbus side and 1 from the chain side. 8reserved revid>=3 hosthide r/o 1?b0 r/o 1?b0 on interface revid 1 and 2 this field is reserved. the hosthide feature is not supported. 9 reserved r/o 1?b0 reserved 10 reserved revid>=3 actasslave r/o 1?b0 r/w 1?b0 on interface revid 1 and 2 this field is reserved. on interface with revid 3 and greater if this bit is set the interface acts as a slave and uses the unit id set in the devnum field. the default is forced on a cold reset and any change will only take effect on a link warm reset. 11 reserved revid>=3 inboundeoc error r/o 1?b0 r/o 1?b0 on interface revid 1 and 2 this field is reserved. on interface with revid 3 and greater this bit is not used. the error reporting is compatible with the older version of the interface and differs from 1.03. 12 reserved revid>=3 droponuninit r/o 1?b0 r/o 1?b0 on interface revid 1 and 2 this field is reserved. the droponuninit feature is not supported. 15:13 captype r/o 3?b001 this field indicates that this is a host/secondary bridge capability type. table 145: hypertransport command register - offset 40 bits [31:16] (cont.) bits name default description table 146: hypertransport link control register - offset 44 bits [15:0] bits name default description 0 reserved r/o 1?b0 reserved 1 crcsyncflooden r/w 1?b0 if set crc errors will cause a sync flood and set the link failure bit, and will therefore jam the link. if clear a sync flood is not generated and the bit not set. crc checking is always enabled and errors are always logged in the crc error bits. 2 crcstarttest r/s 1?b0 if this bit is set the bridge initiates a crc test sequence on the link (see the hypertransport specification for details). the bit is cleared by the hardware when the test is complete, software can then check the crc error bit to check the status of the test. 3 crcforceerr r/w 1?b0 if this bit is set the bridge generates bad crcs on the outgoing link. 4 linkfail r/w 1?b0 this bit is set if a link failure is detected. this bit is persistent through warm reset. if this bit is set link synchronization will not be done and the initialization complete bit will not get set on either end of the link. if this bit is changed by software it will only have effect after the next warm reset. 5 initdone r/o 1?b0 this bit is set by the bridge to indicate that the low level link initialization has completed successfully. 6 eoc r/s 1?b0 this bit may be set by software to indicate this is the last device in a logical chain. if set all received packets are ignored. if the xmitoff bit is clear the bridge will generate nop packets and good crcs on its outgoing link. once set this bit can only be cleared by a fabric reset. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 250 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r 7 xmitoff r/s 1?b0 this bit can be set by the software to shut off a transmitter. when set none of the output pins will toggle. if the eoc bit is set on an active link xmitoff should not be set until the transmitter has driven enough nop packets to fill the receiver?s receive fifos. once set this bit can only be cleared by a fabric reset. 11:8 crcerr r/c 4?b0 when a crc error is received on the incoming link the bridge will set the bit in this field corresponding to the byte lane that had the error. the bcm1250 only supports an 8-bit link, so bit [8] is the only one that will ever be set. software may clear these bits by writing a 1 to them. 15:12 reserved r/o 4?b0 reserved table 146: hypertransport link control register - offset 44 bits [15:0] (cont.) bits name default description table 147: hypertransport link configuration register - offset 44 bits [31:16] bits name default description note that this register matches the hypertransport 1.0 standard, and is a superset of rev 0.17 2:0 maxin r/o 3?b000 this field indicates the bcm1250 only supports an 8 bit input link. 3 dwfcin r/o 1?b0 the bridge is not capable of doubleword flow control. 6:4 maxout r/o 3?b000 this field indicates the bcm1250 only supports an 8 bit output link. 7 dwfcout r/o 1?b0 the bridge is not capable of doubleword flow control. 10:8 widthin r/o 3?b000 this field is fixed for an 8 bit link. 11 dwfcinen r/o 1?b0 the bridge is not capable of doubleword flow control. 14:12 widthout r/o 3?b000 this field is fixed for an 8 bit link. 15 dwfcouten r/o 1?b0 the bridge is not capable of doubleword flow control. table 148: hypertransport link frequency register - offset 48 bits [15:8] bits name default description 3:0 linkfreq r/w 4?b0000 this register sets the maximum transmitter clock frequency for the link. the bcm1250 uses this value to control the pll that provides both transmit and receive internal clocks using the clk100 reference. if the srilinkfreqdirect bit is clear in the sricmd register, these bits have the encoding given in the hypertransport 1.0 standard: 0000: 200 mhz (clk100 x2) 0001: 300 mhz (clk100 x3) 0010: 400 mhz (clk100 x4) 0011: 500 mhz (clk100 x5) 0100: 600 mhz (clk100 x6) 0101: not supported (code for 800 mhz) 0110: not supported (code for 1000 mhz) others: undefined 4 linkfreq r/w 1?b0 if the srilinkfreqdirect bit is set in the sricmd register then the [4:0] field is used to set the pll frequency directly, using the values shown in table 9 on page 31 . the link frequency will be set to clk100 * linkfreq[4:0]/2. the hypertransport link clock frequency must not be set faster than four times the frequency of the i/o bridge 0 clock. if the bridge is set (using the configuration resistor on io_ad[5]) to cpu clock/4 then the hypertransport clock frequency must be less than or equal to the cpu clock frequency. if the bridge is set to cpu clock/3 then the hypertransport link clock must be run at less than or equal to 4/3 of the cpu clock frequency. note that the srilinkfreqdirect bit must be set before the frequency code is written to this register for the alternate frequencies to be used. 7:5 reserved r/o 3?b0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 251 table 149: hypertransport sri command register - offset 50 bits [31:16] bits name default description 0 sipready r/w 1?b0 system initialization process ready. this bit should be set by software when the sri initialization process is complete. the ldt bridge will be held in reset until this bit is set. 1 syncptrctl r/w 1?b0 this bit should be set to enable synchronous pointer control. if the interface is synchronous the pointers in the receive fifo are moved according to a fixed pattern based on the ratio of the load and unload clocks. if the interface is asynchronous the pointers are moved by sampling the incoming receive clock and counting the number of edges. 2 reducesynczero r/w 1?b0 if this bit is set only 128 bit times of zeros will be sent during link initialization rather than the standard 512 bit times. only set during testing. 3 dismulttxvld r/w 1?b0 if clear (default), all 3 virtual channels can send requests simultaneously. if set, only one channel can make a request at a time (as in revid). this bit is for debug use only. 8:4 rxmargin r/w 5?h0 this sets the offset between the receive fifo load and unload pointers. 9 srildtpllcompat r/w 1?b0 this bit should be set for compatibility with 0.17 hypertransport devices. it modifies the behavior for updating the ldtlinkfreq register (the one visible to programmer) and moving it into ldtpllfreq (the shadow copy used to control the pll). older fixed frequency devices need this bit set, so a link cold reset does not alter the link frequency. hypertransport rev 1.0 devices reset their link frequency to 200 mhz on a link cold reset. srildtpllcompat set to 1 => compatible with api ap1011 / sipackets sp1011 srildtpllcompat set to 0 => comply with 1.0 spec. this table summarizes the behavior on reset: ldtlinkfreq ldtpllfreq system reset 200mhz 200mhz link cold reset compat == 0 200mhz 200mhz compat == 1 no change no change link warm reset compat == 0 no change copied from ldtlinkfreq compat == 1 no change no change 10 exp_endian r/w 1?b0 selects endian policy for expansion space. if this bit is clear then all of the expansion space will use the match byte lane policy. if the bit is set then address bit [38] is used to select the endian policy and the address bit is cleared as the request passes through the bridge. 11 reserved r/o 1?b0 reserved 14:12 txinitialoffset r/w 3?b000 this sets the initial offset between the transmit fifo unload and load pointers. 15 srilinkfreqdirect r/w 1?b0 if this bit is clear the hypertransport link frequency is set according to the hypertransport specification revision 1.0. if it is clear a wider range of frequencies can be set. see table 148 on page 250 . table 150: hypertransport isochronous bar - offset 5c bits [31:0] bits name default description 0 isocen r/w 1?b0 if this bit is set then the isocbar and isocignmask are used to force inbound transactions within the specified range to behave as if their isochronous bit is set. 31:1 isocbase r/w 31?b0 this register sets the address bits 35:5 that are compared to force the iscochronous bit. see section: ?force isochronous mode address range? on page 212 . bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 252 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r table 151: hypertransport isochronous ignore mask - offset 60bits [31:0] bits name default description 0 reserved r/w 1?b0 reserved 31:1 isocmask r/w 31?b0 this specifies the mask of bits that are ignored when the comparison is done to force the iscochronous bit. see section: ?force isochronous mode address range? on page 212 . table 152: hypertransport error control register - offset 68 bits [23:0] bits name default description 0 protfatalen r/w 1?b0 if this bit is set a fatal interrupt will be raised when a protocol error is detected. 1 protnonfatalen r/w 1?b0 if this bit is set a nonfatal interrupt will be raised when a protocol error is detected. 2 protsyncflooden r/w 1?b0 if this bit is set a protocol error will cause sync flooding of the hypertransport link and the linkfail bit will be set. 3 ovffatalen r/w 1?b0 if this bit is set a fatal interrupt will be raised when a receive buffer overflow is detected. 4 ovfnonfatalen r/w 1?b0 if this bit is set a nonfatal interrupt will be raised when a receive buffer overflow is detected. 5 ovfsyncflooden r/w 1?b0 if this bit is set a receive buffer overflow will cause sync flooding of the hypertransport link and the linkfail bit will be set. 6 eocnxafatalen r/w 1?b0 if this bit is set a fatal interrupt will be raised when a posted request to a nonexistent address or response that does not match a request is detected. (non-posted requests will receive an nxa error in this case). 7 eocnxanonfatalen r/w 1?b0 if this bit is set a nonfatal interrupt will be raised when a posted request to a nonexistent address or response that does not match a request is detected. (non-posted requests will receive an nxa error in this case). 8 eocnxasyncflooden r/w 1?b0 if this bit is set a posted request needing an nxa or a response that does not match a request will cause sync flooding of the hypertransport link and the linkfail bit will be set. 9 crcfatalen r/w 1?b0 if this bit is set a fatal interrupt will be raised when a receive crc error is detected. 10 crcnonfatalen r/w 1?b0 if this bit is set a nonfatal interrupt will be raised when a receive crc error is detected. 11 serrfatalen r/w 1?b0 the serren bit in the bridge control register determines if an serr will generate an interrupt. if this bit is set a fatal interrupt will be raised, if clear a nonfatal interrupt is used. 12 srctagfatalen r/w 1?b0 if this bit is set a fatal interrupt will be raised when a source tag error is detected. 13 srctagnonfatalen r/w 1?b0 if this bit is set a nonfatal interrupt will be raised when a source tag error is detected. 14 srctagsyncflooden r/w 1?b0 if this bit is set a source tag error will cause sync flooding of the hypertransport link and the linkfail bit will be set. 15 mapnxafatalen r/w 1?b0 if this bit is set a fatal interrupt will be raised when an nxa error response is sent to a request with zero source id. 16 mapnxanonfatalen r/w 1?b0 if this bit is set a nonfatal interrupt will be raised when an nxa error response is sent to a request with zero source id. 17 mapnxasyncflooden r/w 1?b0 if this bit is set an nxa error response to a request with zero source id will cause sync flooding of the hypertransport link and the linkfail bit will be set. 23:18 reserved r/o 6?b0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 253 table 153: hypertransport error status register - offset 68 bits [31:24] bits name default description 0 protoerr r/c 1?b0 this bit will be set if a protocol error is detected on the incoming link. software may clear this bit by writing a 1 to it. in some circumstances this bit will be set by a hypertransport link reset. 1 ovferr r/c 1?b0 this bit will be set if the receive fifo overflows. software may clear this bit by writing a 1 to it. 2 eocnxaerr r/c 1?b0 this bit will be set if a non existent address (nxa) error is returned to a request from the incoming link because the end of chain bit (bit 6 in the link control register) is set. software may clear this bit by writing a 1 to it. this bit will also be set if a request is rejected because the link has not been established (the initdone bit is clear). 3 srctagerr r/c 1?b0 this bit will be set if a response packet is received with a source id that does not match any outstanding request. software may clear this bit by writing a 1 to it. 4 mapnxaerror r/c 1?b0 this bit will be set if a non existent address (nxa) error is returned due to a mapping problem with the request. there are two causes: 1) a packet is received that does not match one of the valid address ranges in figure 43 on page 210 . 2) a packet is received that is decoded as having an address on the hypertransport link and with a zero source id. this indicates that the packet is a peer-to-peer hypertransport transaction, but it originated in the host bridge at the far end of the link and has therefore not been accepted by any device on the link. this bit is also set (but no error packet sent) if a response is received that has source id of zero and did not come from this host. software may clear this bit by writing a 1 to it. 7:5 reserved r/o 3?b0 reserved table 154: hypertransport sri transmit control register - offset 6c bits [23:16] bits name default description 3:0 bufrelspace r/w 4?b0100 this field sets the minimum number of packets that will be sent between buffer release nop packets. if the link is idle buffer release packets are sent immediately. if the link is busy buffer release messages are inserted into the packet stream with this minimum spacing so that the bandwidth is not consumed with flow control traffic. 7:4 reserved r/o 4?b0 reserved table 155: hypertransport sri data buffer allocation register - offset 6c bits [15:0] bits name default description 1:0 needresp r/w 2?b01 this register controls the allocation of the 8 hypertransport receive data buffers among the 3 virtual channels, to allow performance tuning. the "need" fields indicate the minimum allocation at all times to each channel, minus one. that is, a value of 0 indicates a permanent minimum allocation of 1. the total number of buffers "needed" must be less than or equal to 8 or the behavior of the bridge is undefined. if the number of "needed" buffers is less than 8 the allocator will dynamically allocate them to the three channels, subject to the limits set in the "want" fields. the "want" fields indicate how many buffers the allocator should try to have released and outstanding to each channel at all times, minus 1. in the default (reset) case, there are 2 buffers in each category. note that these counts must not be set to 2?b11 (i.e. 4 buffers) or the system may behave in undefined ways. 3:2 neednpreq r/w 2?b01 5:4 needpreq r/w 2?b01 7:6 reserved r/o 2?b00 9:8 wantresp r/w 2?b01 11:10 wantnpreq r/w 2?b01 13:12 wantpreq r/w 2?b01 15:14 reserved r/o 2?b00 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 254 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r table 156: hypertransport additional status register - offset 70 bits name default description 7:0 tgt_done r/w 8'b0 target done counter. this value is incremented every time a target done acknowledgement is received from the fabric. these will happen as a result of the nonposted writes done in configuration space. software may write this field, incrementing will continue from the value written. 31:8 notimp 26b'x not implemented. table 157: hypertransport sri transmit buffer count max register - offset c8 bits [31:0] bits name default descriptions 3:0 pcmd r/w 4?b1111 these fields set the maximum number of each class of buffer the transmitter will use. the classes (posted command, posted data, nonposted command, nonposted data, response and response data) match the buffers in the receiver and fields in the nop flow control packet. nop packets received from the other end of the link will increment the number of buffers that the transmitter believes the receiver has available. if the count reaches the limit set in this register the extra credits will be discarded. this allows a general way to throttle traffic in a particular virtual channel on a link. the maximum counter values should be setup before the sipready bit is set. the values may be lowered in a running system, but the link must be reset before any increase takes effect. 7:4 pdata r/w 4?b1111 11:8 npcmd r/w 4?b1111 15:12 npdata r/w 4?b1111 19:16 rcmd r/w 4?b1111 23:20 rdata r/w 4?b1111 31:24 reserved r/o8?b0 reserved table 158: hypertransport diagnostic receive crc expected - offset dc bits name default description 31:0 rxcrce r/o 32?bx this contains the expected value of the receive crc. table 159: hypertransport diagnostic receive crc received - offset f0 bits name default description 31:0 rxcrcr r/o 32?bx this register contains the actual value received for the crc. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 255 s ystem r eset i nitialization of the h yper t ransport i nterface there are a number of parameters that must be configured in the hypertransport interface before the hypertransport link can come out of reset and the link initialization described in the hypertransport specification can start. these registers should be programmed and then the sipready bit in the sri command register set. once this bit is set the hypertransport interface will come out of reset, remove the link reset, and start the link initialization. most of the configuration is setting up the hypertransport receive and transmit fifo clocks. a high level view of this is shown in figure 50 . data from the fabric is loaded into the receive fifo using the clock that was received with the data. it is unloaded using the internal hypertransport interface clock and passed to the receive logic. data from the transmit logic is loaded into the transmit fifo using the internal hypertransport interface clock and extracted using the link transmit clock. the fifos both buffer clock speed differences and provide time for the data to stabilize as it crosses the clock boundary. figure 50: hypertransport interface clocks and fifos 4 ddr ht pll x(2,3,4,5,6,8,10) link frequency register unload pointer load pointer transmit fifo 8 x 32 bit load pointer unload pointer ht transmit logic ht receive logic receive fifo 8 x 32 bit ht internal clock (f ldtint ) rx data rx clock tx data 32 32 100 mhz reference 8 32 32 tx clock (f tx ) (f rx ) i/o clk bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 256 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r configuration flags in the sricmd register there are three flags in the sricmd register. two of these should be set at the start of initialization. the reducesynczero flag should only be set during debugging; it reduces the number of bit times of zeros during link initialization from the standard 512 to 128. the syncptrctl should be set if the interface is running in synchronous clock mode (using the same reference clock source as the other end of the link) and clear for asynchronous mode. selection of the correct mode depends on the system design, it will normally be coded in to the boot rom but could also be set on the software configuration bits in the system control register. the third flag is the sipready flag. this should be left clear while the initialization is done. once all the registers (including the sricmd register) have been setup this bit should be set. the sipready bit is sticky. once it has been set the only way to clear it is a cold reset. configuration code should check the state of sipready to determine if the full initialization sequence or an abbreviated version is needed. timing registers: srirxden, sritxden, srirxnum and sritxnum the receive timing registers are used when the interface is running in synchronous clocking mode, the transmit registers must always be configured. the registers describe the relationship between the receive clock from the hypertransport link (f rx )and the internal hypertransport interface clock (f ldtint ), and the relationship between the internal hypertransport interface clock and the hypertransport transmit clock (f tx ). note that the receive and transmit clocks used in this discussion are the actual clocks on the link and therefore are half of the data rate. the transmit clock frequency is set in the linkfreq r egister in the hypertransport capability block. the 100 mhz reference clock is multiplied up by the hy pertransport pll to give t he requested frequency. the internal hypertransport interface clock is always one quarter of the transmit clock frequency: f ldtint =f tx /4. the receive clock frequency is set by the device the other end of the link. data is inserted into the receive fifo byte wide sent on both edges of the receive clock, it is removed from the fifo 8 bytes wide clocked on the rising edge of the internal hypertransport interface clock. the data rate ratio is therefore: f rx /4*f ldtint = f rx /f tx . the srirxden and srirxnum registers encode this receive ratio. the numerator is a bit pattern in which a 1 indicates that data should be extracted from the receive fifo. the denominator sets the number of bits in the numerator that are used. two bits from the numerator pattern are examined each internal cycle, starting from bit zero and ending at bit (denominator-1), to determine how many 32 bit words should be read out of the fifo in that cycle. for example if the receive clock from the link (i.e. the transmit clock set in the linkfreq register of the device the other end of the link) f rx =300 mhz and the transmit clock (set in the linkfreq register) f tx =400 mhz then the receive data rate ratio is 3/4. the srirxnum should therefore be set to 32?b1101 (or some similar pattern with three ones and a zero) and the srirxden should be set to 4 to indicate only the bottom four bits of the numerator pattern are used. in the common case where the clock frequency is the same at both ends of the link then the default values of srirxnum = 32?hffff and srirxden = 16 will work. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 257 the transmitter registers work similarly. bits in the numerator indicate that data should be inserted into the transmit fifo from the internal clock. in the bcm1250 or BCM1125h, the clock ratio is fixed to 1/4. data is inserted into the fifo 8 bytes wide on the internal clock and removed byte wide on each edge of the hypertransport transmit clock. these cancel, so the timing registers must be configured to allow data to be inserted every internal cycle. the defaults of sritxnum = 32?hffff and sritxden = 16 are suitable values. receive pointer margin c ontrol in sricmd register the receive fifo is used to separate the link receive clock domain from the internal hypertransport interface clock domain. to allow for the data to become stable and valid some time must be provided between writing an entry in the fifo and reading it. this is done by having an offset (or margin) between the load and unload pointers. the initial separation is configured in the sricmd register. the value set for the initial margin is computed from the minimum margin that is needed once the interface is running, adjusted for the movement of the load and unload pointers during the initialization sequence. (for implementation reasons the value programmed in the configuration register is twice the basic computation, hence the extra doubling in the discussion below.) the configuration register must be set to twice the offset that the unload pointer should have from the load pointer when the link is reset. if the pointers did not move during the initialization process this would simply be: 2*( - margin for data to be stable) this is negative because it is measured from the load pointer to the unload pointer, which must always be behind. (since the pointers cycle around the fifo the offset must be taken mod 8 to get the actual value programmed.) in asynchronous mode the load and unload pointers are stationary during initialization so the correct value can be obtained directly from this computation. in synchronous mode the load and unload pointers are always being moved according to the ratio set in the srirxnum and srirxden registers, so a correction must be applied. in synchronous mode, the received sync pattern indication from the link passes through four synchronization stages clocked by the internal hypertransport clock on its way in to the link initialization logic. the load pointer for the receive fifo will advance every two receive clocks (the incoming data is on every edge of the clock, so the four byte fifo width builds up in two clocks). the minimum advance of the fifo load pointer during the sync synchronization is therefore: (time for sync propagation to initialization logic)/(time per load pointer increment) = (4 * internal clock period)/(2 * receive clock period) = 2*f rx /f ldtint the fifo wraps every eight entries, so this value is taken modulo 8. the pointer offset must also be adjusted to take into account the possible movement of the unload pointer. the worst case movement of the unload pointer must be used, since that brings it closest to the load pointer. the maximum unload pointer movement can be computed from the srirxnum value. if there are two adjacent 1s anywhere (including over the wrap from bit [srirxden-1] to 0) in the numerator then it is possible for two (32 bit) words to be extracted from the fifo during sync. if there are only 10 and 01 patterns for adjacent bits then only one word can be extracted during sync. on the bcm1250 or the BCM1125h, the recommended time allowed for the data to become stable is two cycles. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 258 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r putting the three terms together, the value to be programmed for the rxmargin field in synchronous mode is: rxmargin = 2*(load pointer updates - unload pointer updates - margin for data to be stable) = 2*(2*f rx /f ldtint - (1 or 2) - 2) in asynchronous mode the rxmargin field should be programmed to twice the number of receive clock cycles for the data to settle. the settle time recommended for the bcm1250 or BCM1125h is 7ns, so in asynchronous mode: rxmargin = 2*7ns*f rx transmit pointer initial off set in the sricmd register the transmit fifo pointers must be offset to take account of the seven stages of synchronization using the hypertransport transmit clock that are applied to the reset pulse, and to allow time for data settle margin. the minimum number of internal hypertransport clocks taken for the synchronization time is given by: mininternalsyncclocks = 7*transmitclkperiod / internalclkperiod = 7*f ldtint /f tx = 7/4 = 1 (rounding down) the minimum advance of the load pointer can be found from the sritxnum value. in this case the numerator is all 1s so the minimum advance is 2, if the numerator had 10 or 01 pairs of bits then the minimum advance would be 1. the recommended data settle margin is 2. this gives: txinitialoffset = mininternalsyncclocks - minpointeradvance - margin = 1 - 2 - 2 = -3 mod 8 = 5. error control register the error control register sets the error handling behavior of the hypertransport interface for both the standard hypertransport errors and the additional ones reported on the bcm1250 or BCM1125h. the possible responses to errors are: to raise the ldt_fatal_int interrupt, to raise the ldt_nonfatal_int interrupt and to flood the link with sync packets. any of these may be selected as the response to any of the errors. (the crc error causing sync flooding is set in the standard link configuration register). transmit control register the transmit control register must be configured to set the minimum number of packets that will be sent between nop packets that are reporting buffer releases to the device on the other end of the link. if the transmitter is idle, the nop packet will be sent as s oon as the buffer is free. if the transmitter is busy and becomes idle the nop packet will be sent when the link idles. if the transmitter is continually busy the nop packets will be spaced by the number of packets set in this register. if the value is set too low then the nop packets will frequently interrupt transmission of data, so the link utilization will fall. if the value is set too high then buffer releases will not be reported in a timely manner, so the device the other end of the link may throttle its transmissions unnecessarily. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 259 buffer control: txbufcountmax and databufalloc the transmit buffer count max register sets the maximum number of buffers the transmitter will use in each of the six buffer classes described in the hypertransport specification. the classes (posted command, posted data, nonposted command, nonposted data, response and response data) match the buffers in the receiver and fields in the nop flow control packet. nop packets received from the other end of the link will increment the number of buffers that the transmitter believes the receiver has available. if the count reaches the limit set in this register the extra credits will be discarded. this allows a general way to throttle traffic in a particular virtual channel on a link. the databufalloc register allows allocation of the hypertransport receive data buffers between the three virtual channels. the minimum number of buffers that must remain allocated to each channel is specified, along with the number of additional buffers that the dynamic buffer allocator should try to make available for that channel. h yper t ransport r esets there are four reset conditions associated with the hypertransport. this section describes them and their actions on the hypertransport link and interface. the four resets are: 1 system cold reset. a system cold reset is caused by the assertion of coldres_l or the setting of the system configuration register system_reset bit. this reset causes the subsequent assertion of all other resets detailed here. 2 system warm reset. a system warm reset is caused by the assertion of reset_l or the setting the system configuration register sb_softres bit and results in the assertion of link reset. 3 hypertransport link power ok (ldt_pwrok). this open drain output is driven and received by the interface. the hypertransport link is inactive if this signal is not asserted. 4 hypertransport link reset (ldt_reset_l). this open drain output is driven and received by the interface. the hypertransport link is reset when this signal is asserted, a cold link reset will be performed if ldt_pwrok is deasserted and a warm link reset if ldt_pwrok is asserted. following a system cold reset the interface will drive the hypertransport link controls to ensure ldt_pwrok will remain deasserted and ldt_reset_l will remain asserted until the sipready bit has been set in the hypertransport sri command register. once the bit is set ldt_pwrok will be asserted and 1ms later ldt_reset_l will be deasserted to start the cold link initialization. these are inputs as well as open drain outputs, so other devices in the chain can hold off starting the link (for example in a double hosted link the parts at each end of the link may take different lengths of time to complete their initialization and set sipready). note that writing the sri configuration registers and setting of the sipready bit should only be done after a system cold reset, the sipready bit must not be touched during link resets. as required by the hypertransport specification, a deassertion of ldt_pwrok is caused by clearing the warm reset bit in the hypertransport command register and setting the secbusreset bit in the hypertransport bridge control register. this is effectively a cold reset on the hypertransport link and also causes the assertion of the link reset. as required by the hypertransport specification, an assertion of link reset is caused by setting the warm reset bit in the hypertransport command register and setting the secbusreset bit in the hypertransport bridge control register. this is effectively a hypertransport link warm reset. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 260 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r the registers that make up the hypertransport br idge header are reset by both system resets and are unaffected by link reset with the following exceptions: 1 the hypertransport sri command register is reset on system cold reset and persistent across system warm reset. 2 the following bits in the hypertransport bridge secondary status register are set to zero on a system cold reset and are persistent through a system warm rese t: sigdtgtabort, rcvdtgtabort, rcvdmstrabort, detserr. 3 the following bits in the hypertransport link control register are reset by link reset: initdone, eoc, xmitoff. 4 the linkfail bit and crcerr bits in the hypertransport link control register are reset to zero on a system cold reset and are persistent through a system warm reset. 5 the hypertransport link frequency register is cleared by system cold reset and is persistent across system warm reset. beyond that, it's behavior is determined by the srildtpllcompat bit in the hypertransport sri command register. if the srildtpllcompat bit is set, the link frequency implementation becomes backwards compatible with hypertransport specification revision 0.17, which does not allow for dynamic frequency negotiation. in this mode, the hypertransport link must come up at a static frequency and therefore writes to the linkfrequency register take effect immediately. it is strongly suggested that this be done prior to setting the sipready bit in the hypertransport sri command register and at no other time. if the srildtpllcompat bit is clear, a write to the link frequency register will take effect only on the next link warm reset. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 8: pci bus and hypertransport fabric page 261 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 262 section 8: pci bus and hypertransport fabric document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 263 section 9: ethernet macs i ntroduction the bcm1250 includes three ethernet macs. the BCM1125 and BCM1125h include two ethernet macs. the macs support the 10 mbps, 100 mbps and 1 gbps ethernet standards. they can operate in full or half-duplex mode at all speeds. the mii (10/100 mbps) or gmii (1 gbps) standard interfaces are used to connect to external phy (physical interface) chips. the minimum and maximum size of a packet is programmable, giving support for jumbo packets up to 16k-1 bytes. for half-duplex operation the mac supports programmable backoff and retransmission following a collision. a set of rmon counters are updated automatically at the end of each packet transmission or reception, these may be read by the cpu at any time to gather interface statistics. in addition to the standard ethernet mode, each interface can be put into a bypass mode where the ethernet protocol processing is disabled and the interface acts as a packet fifo. in this the gmii pins are used to provide an 8-bit data path in each direction that can carry packet or unframed data. selection of ethernet or 8- bit packet fifo is done by software. the interfaces are identical and independent. the registers and interrupts associated with each are differentiated by appending the interface number to their names. on the bcm1250 the interfaces are _0 , _1 and _2 . on the BCM1125/h the interfaces are _0 and _1 . accesses made to the address range allocated to a nonexistant mac may cause all macs to exhibit unpredictable behaviour. the following sections describe one of the macs. the mac interfaces can be replaced by packet fifo interfaces that are 16-bits wide in each direction. pins from mac e0 and e1 are reassigned to packet fifo interface f0 on the bcm1250 or f on the BCM1125/h, and on the bcm1250 pins from all three macs are reassigned to packet fifo interface f1. selection between ethernet and packet fifo operation is done by software. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 264 section 9: ethernet macs document 1250_1125-um100-r i nterface o verview figure 51 shows the block diagram of a single ethernet interface. the interface to the system bus is provided through i/o bridge 1. this allows the cpu to access the interface control registers, the rmon statistical counters and the dma control interface. it also provides the connection from the dma engines into the part. figure 51: ethernet interface block diagram i/o bridge 1 receive dma transmit dma receive transmit fifo fifo packet fifo ethernet or packet fifo select gmii interface interface control data data packer unpacker ethernet or packet fifo select and synchronizer control registers rmon counters address filter receive dma channel engine to zbbus mac rx flow rx tx flow tx selector or packet interface user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 265 the dma controllers are described in section7: ?dma? on page 147 . on the transmit side there are two dma channels which are serviced using a weighted round robin algorithm. in the receive direction there are also two channels, the packet header is used to select which will be used for delivery. the transmit packet flow starts with the packet being dmaed from memory into the transmit fifo. the fifo is not intended to store the complete packet, it is there to buffer the line rate from the system bus. the dma controller will fetch 32 byte cache blocks as required to keep the fifo filled. the controller can be configured to either fetch one or two blocks at a time. the memory performance will be improved by fetching two blocks at a time since the second is likely to hit the memory page opened by the first, however it lowers the granularity of control over the fifo. the data unpacker extracts 64 bit double-words from the fifo and forwards them as a byte stream to the protocol engine. either the ethe rnet mac engine or the packet fifo protocol bypass path is selected. for successful transmission one byte must be sent to the protocol engine every cycle, this is enabled by only starting to send a new packet when enough data has been written in to the fifo to buffer the dma latency. the ethernet mac protocol engine formats the packet according to the ethernet specification, executes the mac protocol to gain access to the transmission medium and sends the packet to the (external) physical layer interface over the gmii pins. it will also respond to flow control requests and block packet transmission as required. the packet fifo protocol engine generates simple framing signals for the external interface, but otherwise acts as a bypass path for data to the gmii pins. the receive packet flow starts with a byte stream being delivered from the physical layer device over the gmii pins. bytes are sent either to the ethernet or packet fifo protocol blocks. the protocol engine will validate the packet, strip the mac layer overhead and forward the data to the packing unit. the received bytes are packed into 64 bit double-words and inserted into the receive fifo. again, the fifo just provides a buffering function to cover the dma latency. the receive dma engine will extract 32 byte cache blocks from the fifo and transfer them into memory. the receive protocol engine can also request flow control, it will do this either under software control or if the dma engine is running out of buffers for incoming packets. a set of registers in the control section allows the interface to be configured and status to be read. the mac must be configured before it is used. after the system has been reset the transmit section, receive section and protocol engine are all held in reset until enabled by software. there is one main interrupt associated with each interface. it combines the interrupts from the transmit and receive sides of each of the two dma channels and the interrupt from detection of errors. there is a second interrupt that can be enabled to split the dma channels. when the second interrupt is enabled it signals events from the channel 1 transmit and receive dma engines, and the main interrupt only signals events from the channel 0 dma engines and error conditions. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 266 section 9: ethernet macs document 1250_1125-um100-r p rotocol e ngine and gmii/mii the ethernet mac engine performs all the mac layer processing needed to comply with the ieee 802.3 standard at 10 mbps, 100 mbps and 1000 mbps. it interfaces to the receive and transmit fifos to move data into and out of the system, and connects to an external physical layer interface (phy) using the standard mii (media independent interface) connection for 10/100 mbps operation and the gmii for gigabit operation. many of the protocol parameters are programmable. they must be set to the correct values for ieee 802.3 operation, but may be changed in other applications. as well as the basic protocol processing during transmission the engine can: automatically retry packets that experience transmission errors during the first few bytes. insert or remove a vlan tag. append padding to short packets to meet the minimum frame size. overwrite the source address field in the packet with the mac's own source address. append a crc to the end of the packet. during reception the protocol engine can: automatically drop packets that have errors during their first few bytes. filter incoming packets and automatically discard any with a destination address that does not match. both exact and hash-based matching are available. flag errors and packet type information in the dma descriptor. the protocol engine can run the 10 mbps, 100 mbps and 1000 mbps protocol variants and supports full and half-duplex operation at all speeds. typically the external phy would support auto-negotiation of the line parameters. during initialization the software will read the negotiated state using the management interface to the phy and configure the mac accordingly. the protocol engine implements flow control. it will back-pressure the link when software explicitly requests or when the number of buffers available to the receive dma engine falls below a threshold. in half-duplex mode back-pressure is applied by forcing collisions or a fake carrier on the line, in full-duplex mode flow control (pause) frames are sent. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 267 e thernet f rame f ormat the ethernet frame format is shown in figure 52 . figure 52: ethernet frame format preamble sfd destination address source address type length data crc ifg ifg vlan frame ss ss ifg_tx ifg_thrsh min packet size max packet size 7 1 6 6 2 46-1500 4 preamble sfd destination address source address type length data ifg ifg ss ss 7 1 6 6 4 46-1500 4 crc 2 vlan tag standard frame previous frame previous frame 4 defer to crs ignore crs bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 268 section 9: ethernet macs document 1250_1125-um100-r the frame is broken up into the following fields: table 160: ethernet frame fields name description ifg inter-frame gap. this is the period that the link is idle between frames. the size of the gap used by the mac is programmable. the ifg_tx parameters in the mac_frame_cfg register sets the gap that will be used after reception and transmission of a packet. the ifg_thrsh threshold sets the size of the end of the gap in which the mac does not check the carrier before transmitting. preamble the preamble is used to allow other devices to detect the carrier and synchronize with the transmitter. alternating ones and zeros are sent. sfd the start of frame detect byte is used to mark the start of the active frame. it is a single byte with the value 8'hd5. destination address the destination address is the 6 byte unique ethernet address that this frame is intended for. packets with the destination address ff-ff-ff-ff-ff-ff are broadcast packets, and those with the least significant bit of the first byte (i.e. the first bit sent on the wire) set are multicast packets. the interface will filter incoming packets based on this field. source address the source address is the 6 byte unique ethernet address of the sender of the frame. during packet transmission the interface can automatically overwrite an old source address with its own. type/length the meaning of the type/length field depends on whether the packet is sent in 802.3 format or ethernet format. the field value is a 16 bit number, where the first byte is the most significant 8 bits and the second byte is the least significant 8 bits. if the value of the field is less than or equal to 1500 then this is an 802.3 format frame and this field gives the length of the data field. if the value is greater than 1535 then this is an ethernet format frame and this field gives the type. the receive interface can be set to check this length against the actual packet length, and report an error if they differ. data the data portion of the packet is the (layer 3) da ta that is being transported from the source to the destination. the standard gives the minimum and maximum sizes of the data as 46 and 1500 bytes (giving minimum and maximum packet sizes of 64 and 1518 bytes). both can be changed in the mac_frame_cfg register to support jumbo packets. crc the crc (also known as frame check sequence or fcs) is a 32 bit cyclic redundancy check calculated over all the bytes in the packet from the first destination byte to the last data byte. it is normally appended to the frame during transmission and checked during reception. the crc is formed using the crc-32 polynomial: x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 +x 1 + 1 the partial crc accumulator is initialized to 32?hffffffff at the start of the packet. the 32 bit crc is transmitted most significant byte first. the interface can automatically insert the crc during transmission, this is selected on a per- packet basis in the dma descriptor. if this is disabled the crc must be provided as part of the data from the transmit fifo. the mac will always check the transmitted crc and log an error if a packet has been sent with a bad crc. vlan tag the vlan tag is not part of the ethernet standard. it is an extra four byte header that is used when encapsulating other packets into a "virtual lan" link. the interface can insert, replace or remove vlan tags from packets during transmission. this is selected on a per-packet basis in the dma descriptor, if the vlan tag is altered then automatic crc generation is also enabled. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 269 p repended h eader f rame f ormat in devices with system revision indicating periph_rev3 or greater the mac interface supports a modified frame format that has an additional header prepended before the ethernet frame. the crc can be set to cover the prepended header and ethernet frame or just the ethernet frame (or a combination). ignoring the framing (ifg/preamble/sfd for ethernet, so p/eop marks on first and last by tes for packet fifo modes) the prepended header format is shown in figure 53 . this figure shows the crc offset pointing to part way through the prepended header which is unusual, the standard cases ar e when the crc_offset is zero (i.e. the crc covers everything) or the crc_offset is equal to the pkt_offset (i.e. the crc covers the ethernet frame and not the prepended header). the crc_offset must be less than or equal to the pkt_offset, if it is greater the behavior of the interface is unpredictable. figure 53: prepended header format the pkt_offset and crc_offset must be a multiple of 8 bytes. an offset of zero indicates there is no offset and the start of the packet is used. the maximum offset is 248 (31*8) bytes. there are separate registers to set the offsets on the transmit and receive sides (and their values may be different). in both cases the crc offset specifies the first byte of the packet that will be included in the crc calculation. for the transmit side the tx_pkt_offset is used to locate the ethernet header for replacement of the source address, and the vlan tag position for automatic insertion, removal or replacement of the vlan tag. on reception the rx_pkt_offset is used to specify the start of the ethernet header for the address filtering and for extraction of the packet type. the figure also shows the iphdr_offset. this identifies the start of the ip header in the packet for checksum checking (both ipv4 header checksum and tcp checksums are checked) and is discussed in later sections. to allow for networks that have a mix of vlan and non-vlan packets the interface can be configured to automatically add 4 bytes to the iphdr_offset when a packet with a vlan tag is received. destination address source address type length data crc vlan frame with prepended header ss ss pkt_offset min packet size max packet size n*8 6 6 2 46-1500 4 destination address source address type length data ss ss 6 6 4 46-1500 4 crc 2 vlan tag standard frame with prepended header prepended header crc_offset covered by the crc prepended header iphdr_offset 4 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 270 section 9: ethernet macs document 1250_1125-um100-r p rotocol e ngine c onfiguration the basic encapsulation parameters are set in the mac_frame_cfg register. this allows configuring of the inter-frame gap, maximum backoff time, slot size, minimum frame size and maximum frame size. this must be programmed to the correct values for ieee 802.3 operation at 10 mbp/s and 100 mbp/s. for gigabit operation the slot_size is automatically increased to 512 byte times (rather than 512 bit times) but software must half the ifg values; none of the other parameters should be altered. in networks configured to use jumbo packets the maximum frame size should be increased to match the rest of the network. parameters should only be altered while the protocol engine is held in reset. care must be used when altering the values from their standard ones, typically all endpoints on the network must be configured similarly. a detailed description of each of the parameters is given in the register description in table 180 on page 307 . the effective slot size is adjusted by adding a 10 bit signed offset in bit times to the 512 bit times or 512 byte times selected by the data rate. the offset adjusts the mac timing to take account of the number of cycles of latency through the phy and back. typically the field will be a small positive number. the lfsr_seed is the only parameter in the mac_frame_cfg register that can be altered at any time and that can be altered without violating the 802.3 standard. whenever it is written the value written sets the lowest eight bits of the linear feedback shift register that generates the pseudo-random backoff following a collision. the rest of the protocol engine configuration is done in the mac_cfg register. for ethernet operation the bypass_sel bit must be clear. the ss_en bit must always be set unless the part is being run in a test mode. ethernet packets are recovered into a byte stream before being put into the 64 bit wide receive fifo, and data is read in 64 bit chunks from the transmit fifo and converted to a byte stream before it is sent. the system endian configuration is used to correctly order the bytes so that the first byte on the wire is at the lowest memory location. the flow control portion of the protocol engine must also be programmed with the flow control mechanism and for full-duplex links the number of slot times to request the peer to pause transmission. these are set in the mac_cfg register in the fc_cmd and tx_pause_cnt fields. control of the movement of data between the transmit and receive fifos and the protocol engine is also done in the mac_cfg register. these settings are discussed in the transmit and receive sections below. errors generated in the interface are signalled in the mac_status register. bits in this register are set when an error is detected and also reflect the interrupt state from the dma engines. whenever the register is read the error bits are cleared. there is a mask register mac_int_mask associated with the status register. if both the mask and status bits are set for any of the error conditions or dma channels then the mac interrupt is raised. reading the mac_status register will clear the error bits, but the dma channels must also be serviced before the interrupt is removed. i nterface to phy the interface to the phy is done through the standard gmii/mii interface. this provides an 8 bit path each direction for gigabit operation and a 4 bit path for 100 mbp/s or 10 mbp/s operation. the phy does the appropriate encoding for the link for transmission, and will deserialize the incoming data. the phy reports carrier sense, collision and code violation to the protocol engine. in most cases software will interrogate the phy to discover the link speed and duplex settings. these are obtained either from auto-negotiation or based on the phy capabilities. the settings must be used to configure the mac_cfg register. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 271 t ransmitter o peration t ransmitter c onfiguration the transmitter clock is accepted as an input from the phy device for 10/100 mbit/s operation. however, for 1 gbit/s operation the data lines are clocked at 125 mhz so the clock is forwarded with the data. in this case the reference clock input is used (on the bcm1250, the refck01 pin is for interfaces e0 and e1, and the refck2 pin for interface e2; on the BCM1125/h, refck0 is for e0 and refck1 for e1). the clock source is configured by the mac speed selection in the mac_cfg register. the transmit fifo is a 64 bit wide fifo with 128 entries. figure 54 shows the thresholds that are used to configure it. when the fifo has space for data it will signal the dma engine to request data. the tx_wr_thrsh field in the mac_thrsh_cfg sets the number of empty entries there must be in the fifo before it will request data. the dma engine fetches either 32 bytes or 64 bytes at a time, so this value should be set to 4 or 8. the data from the transmit fifo is read out by the protocol engine for transmission. once transmission of a packet has started the dma engine must ensure that there is always data in the fifo when the protocol engine needs it. if the fifo is empty at any time before the end of the packet then an underflow error is reported and transmission fails (in encoded packet fifo mode the transmission will not fail, instead cycles with no valid data will be inserted in the link protocol). to reduce t he likelihood of the fifo becoming empty the tx_rd_thrsh threshold can be set to ensure a certain number of entries have been written to the fifo before transmission starts. figure 54: transmit fifo thresholds errors that happen between sop and this entry can be automatically retried fifo must be filled to here before sop will be sent 64 bit wide tx_rd_thrsh tx_rl_thrsh start of packet s o p tx_wr_thrsh the fifo will request data if at least this much is empty bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 272 section 9: ethernet macs document 1250_1125-um100-r in half-duplex operation the ethernet protocol expects collisions to occur, and relies on them to share access to the transmission medium. these collisions will only occur at the start of packet transmission, and the interface will backoff for a random period before retrying the transmission. the maximum backoff time is exponentially increased (up to a maximum 1024 slot times) each time a collision is encountered. if the collision is detected early in the packet the interface will automatically backoff and retry. if a collision happens late in the transmission then the packet is dropped. once transmission has begun entries are retained in the transmit fifo until tx_rl_thrsh entries have been transmitted, if an error is detected during this time the packet can be automatically retried. retaining the start of the packet in this way is enabled by setting the tx_hold_sop_en bit in the mac_cfg register. the errors that will cause automatic retry are also selected in this register. table 161 describes all the transmission error conditions, and lists the bit that must be set to enable automatic retry for them. table 161: transmission error conditions error bit to set for automatic retry description collision retry_en collisions near the start of the frame are an expected part of the ethernet protocol, and should always be retried. excessive collision ret_drpreq_en after 16 attempts to transmit a frame have resulted in a collision the interface will report that excessive collisions have happened. this condition normally indicates a serious problem with the link (although it will occasionally be encountered on a large very busy ethernet), in most cases the packet should not be automatically retried. note that this error and late collisions use the same bit to enable automatic retry. excessive collisions will set the excol_err bit in the mac_status register. late collision ret_drpreq_en the ethernet protocol sets the minimum packet size so that all collisions will be seen during the transmission of a minimum length packet. any collision after the minimum length has been sent is a late collision and indicates a serious error. late collisions can be caused by the ethernet segment being longer than allowed by the specification, or by some other station on the segment turning on or off or violating the standard. in most cases the packet should not be automatically retried. note that this error and excessive collisions use the same bit to enable automatic retry. late collisions will set the ltcol_err bit in the mac_status register. underflow ret_ufl_en an underflow error is reported when the transmit protocol engine finds the transmit fifo empty during transmission of a frame. this will happen if the dma (or external agent in direct mode) has been unable to write data to the fifo at the rate of the transmission. the tx_rd_thrsh threshold can be adjusted to avoid underflows by providing a data buffer in the fifo to cover the request latency. in normal operation the underflow error may occasionally occur if the dma engine is locked out from the bus or memory, and this could be automatically retried. if automatic retry is enabled care must be taken to ensure it is not being applied to every packet. if the read threshold is set too low, then all packets will get an underflow shortly after transmission starts (leading to a runt packet being sent). the time they take to be retried could cover the extra time needed to fetch data into the fifo so they succeed on a second attempt. this situation should be fixed by increasing the read threshold. a fifo underflow will set the tx_undrfl bit in the mac_status register. overflow none cannot be retried an overflow error is reported when the dma engine (or external agent in direct access mode) attempts to write to the transmit fifo when the fifo is full. the data written is lost. during dma this error will only be seen if the tx_wr_thrsh parameter is incorrectly set. a fifo overflow will set the tx_ovrfl bit in the mac_status register. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 273 automatic retry would normally only be enabled for collisions since the other conditions could indicate a more serious problem (once the system is known to work automatic retry could be added for occasional underflows). the gigabit ethernet standard allows bursts of packets to be transmitted without requiring the link be released and reacquired. this is enabled by setting the burst_en configuration bit, which should only be set when the mac is configured for half-duplex 1000 mbp/s operation. t ransmit p ath each mac has two transmit dma channels associated with it. if only one is enabled or only one has descriptors available then it is selected for transmission. if both channels are enabled and have packets available then the weights set in the mac_txd_ctl register are used to select which is used. the number of packets selected by the weight are sent from one dma channel then the other is serviced for the number of packets set in its weight; if a channel becomes empty then the other channel immediatly starts. (note that if both channels are enabled and given weights of zero then no packets will be transmitted.) if the packets in each dma channel are the same length (or on average the same length) then this will share the transmission bandwidth according to the weights. if the packets are on average of very different lengths the weights can be skewed accordingly. the selected dma channel will write a packet into the transmit fifo, with the start and end specially marked for the protocol engine. the packet to be transmitted is encapsulated in the ethernet frame described above. the inter-frame gap, preamble and sfd are automatically prepended before data read from the fifo. the data is then copied from the fifo to form the body of the packet. there are six manipulations that the protocol engine can perform, configured per packet by options in the dma descriptor: replacement of source address. the source address that is in the packet supplied by the dma engine can be overwritten with the address of this interface that has been set in the mac_ethernet_addr register. removal of vlan tag. the four bytes of vlan tag can be dropped from the packet, converting a vlan packet into a regular ethernet packet. insertion of vlan tag. the four bytes in the mac_vlantag register can be inserted into the packet just after the source address, converting a standard ethernet packet into a vlan packet. replacement of vlan tag. the four bytes in the mac_vlantag register overwrite the four bytes in the vlan tag position in the packet. padding short packets to the minimum frame size. insertion of crc. the four byte crc can be automatically replaced in the packet or appended to it. if any of the other modifications are done the crc will be replaced to ensure the interface uses the correct crc for the data sent. during packet transmission the protocol engine always calculates the crc of the frame. this value will be inserted if the interface is configured to automatically append the crc. the crc that is transmitted will always be compared to the crc that was calculated. if the crc was automatically generated they will always match. if the crc was supplied through the transmit fifo and it does not match the calculated one then a transmit crc error is reported. in packet fifo mode the only packet modification that can be done by the transmitter is to append the crc. crc error none cannot be retried the transmitted crc is compared to the crc that was computed over the frame, and this error is raised if they differ. if the interface is automatically appending the crc, then this error will never happen. if the crc is being supplied with the data then this error indicates that the supplied crc was bad, and that the packet will be rejected by the recipient. table 161: transmission error conditions (cont.) error bit to set for automatic retry description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 274 section 9: ethernet macs document 1250_1125-um100-r r eceiver o peration r eceiver c onfiguration the receive fifo is a 64 bit wide fifo with 64 entries. when the fifo contains data it will signal the dma engine to request emptying. the rx_rd_thrsh field in the mac_thrsh_cfg register sets the number of valid entries that must be in the fifo to request emptying. the dma engine transfers in blocks of 32 bytes so this field should normally be set to four entries. the threshold is overridden when the end of a packet is in the fifo, since these are unlikely to be correctly aligned. figure 55: receive fifo thresholds the receiver will hold off informing the dma engine of the arrival of a new packet until successful reception of the first few bytes. the rx_rl_thrsh field in the mac_thrsh_cfg register sets the number of entries that must be written to the fifo before it signals that data is available. if the end of the packet is received the data is always reported to the dma engine. if there is any reception error before this point then the packet can be automatically dropped by flushing the data in the fifo. the error will still be counted in the error statistics. if the drp_errpkt_en bit in the mac_cfg register is set then all packets with errors will be thrown on the ground in this way. if this bit is clear then more selective bits in the mac_cfg determine whether packets with errors are dropped or delivered with an error status. regardless of any of these settings, errors that are detected after the rx_rl_thrsh threshold has passed are always delivered with an error status. for example, if the rx_rl_thrsh is set to 8 and the mac detects a runt packet (shorter than the 64 byte minimum size ethernet packet) the dma engine will never be told about the packet and it will be automatically discarded. errors that happen between sop and here can cause the packet to be dropped once the rl_thrsh has been passed the fifo signals data available if this number of entries are valid or this range contains the end of packet 64 bit wide rx_rl_thrsh rx_rd_thrsh start of packet s o p user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 275 automatic discard can be triggered by any error that happens (fcs error, code error, dribble error, runt error, oversize error or length error) while the fifo is locked (i.e. less than the number of entries set by rx_rl_thrsh have been written into the receive fifo after the start of a given packet). table 162 lists the bits in the mac_cfg register that should be set to enable automatic dropping selectively for each of the error types. table 162: receiver error conditions error bit to set for automatic dropping description crc error drp_fcserrpkt_en a frame check sequence or crc error happens when the crc field in the final four bytes of the received packet does not match the crc that has been calculated for the data that was received. this error indicates that the data in the packet has been corrupted during transmission. note that because the automatic packet dropping can only be done early in the packet (set by rx_rl_thrsh) longer packets with a crc error cannot be dropped and will be received marked with an error. code error drp_codeerrpkt_en a code error is reported for any error signalled by the phy device. the details depend on the encoding used and the particular transmission medium. this error will usually be signalled because received data did not match a valid encoding, but it could also be signalled by loss of light in an optical medium, or the clock recovery block losing lock. a single code error can be ignored, but when multiple code errors are seen the phy status should be checked using the management interface. dribble error drp_drblerrpkt_en in 10 mbp/s and 100 mbp/s operation the data received from the phy over the gmii interface is smaller than a byte (1 bit per clock for 10 mbp/s and 4 bits per clock for 100 mbp/s). however, the length of a valid ethernet packet is always an integral number of bytes. if a packet is received where this is not the case a dribble error is reported (this error is sometimes called an alignment error). this error can never happen during gigabit operation because the interface from the phy is 8 bits wide (any similar error would be reported by the phy as a code error). runt packet drp_rntpkt_en a runt packet is any packet that is shorter than the minimum packet size. the minimum packet size that is used by the mac is configurable in the mac_frame_cfg register, for compliance with ieee 802.3 this size will be set at 64 bytes. oversize packet drp_oszpkt_en an oversize packet is any packet that is larger than the maximum packet size. the maximum packet size that is used by the mac is configurable in the mac_frame_cfg register, for compliance with ieee 802.3 this size will be set at 1518 bytes. if a packet is received that is longer than this size it will be truncated at one byte longer than the maximum frame size and marked with an error. i.e. if the max frame size is set to 1518 bytes and a packet of length 4000 bytes is received from the phy, the dma engine will transfer 1519 bytes to memory and in the start of packet dma descriptor status information software will see the bad packet flag set and a length of 1519 bytes. note that because the automatic packet dropping can only be done early in the packet (set by rx_rl_thrsh) in most cases oversize packets cannot be dropped and will be received marked with an error. length error drp_lenerrpkt_en if the packet type/length field is less than 1500 then it holds the length of the data portion of the packet. a length error is signalled if this does not match the number of bytes that were actually received for the data section. note that because packets may be padded to the minimum frame size a length error is not reported if the packet that is received is longer than the size given in the header. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 276 section 9: ethernet macs document 1250_1125-um100-r at the end of the packet the protocol engine can write one additional entry into the fifo containing status for the packet. this is used by the dma controller to update the length and flags field in the first dma descriptor of the packet. appending of this status word is enabled by setting the ap_stat_en bit in the mac_cfg register, this bit must be set when the interface is configured for ethernet operation and must be clear in packet fifo mode. r eceive p ath the protocol engine processes all packets arriving from the phy, removes the physical layer encapsulation and passes them into the receive fifo. the receive dma engine will remove data from the fifo and transfer it into packet buffers in memory. the receiver is always active, regardless of the full- or half-duplex selection. the packet is checked for errors during reception, and the crc is computed and compared with the value in the packet. if an error is detected early in packet reception it will not have started to be dma?ed and the packet can be dropped. if an error is detected after dma has started, the dma will be completed and the error flagged in the status bits written back to the descriptor. the dropping of packets is enabled by holding the first few entries in the receive fifo and not informing the dma logic that there is data to extract until a threshold has been reached. if the error happens before the threshold then the fifo pointer can be restored to the entry that holds the start of the packet, and the packet is dropped. underflow none an underflow error is reported when the receive dma engine (or external agent in direct mode) reads the receive fifo when it is empty. the data returned is unpredictable and the fifo pointers will not change. during dma this error will only be seen if the rx_rd_thrsh parameter is incorrectly set. an underflow will set the rx_undrfl bit in the mac_status register. overflow none an overflow error is reported when the protocol engine attempts to write to the receive fifo and it is full. this indicates that the dma engine (or external agent in direct mode) is not emptying the fifo fast enough. the data written is lost. a fifo overflow will set the rx_ovrfl bit in the mac_status register. table 162: receiver error conditions (cont.) error bit to set for automatic dropping description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 277 d estination a ddress f iltering the mac will filter received packets based on their ethernet destination address. packets that pass the filter are received, those that do not are never delivered to the dma engine. figure 56: receive address filter mac_addr 0 mac_addr 1 mac_addr 2 mac_addr 3 mac_addr 4 mac_addr 5 mac_addr 6 mac_addr 7 ff_ff_ff_ff_ff_ff dest address crc bits [9:1] 511 448 447 484 483 320 329 256 255 192 191 128 127 64 63 0 mac_hash7 mac_hash6 mac_hash5 mac_hash4 mac_hash3 mac_hash2 mac_hash1 mac_hash0 index accept match > bcast_en broadcast direct_inv mcast_en mcast_inv ucast_en ucast_inv ucast_pkt mcast_pkt packet type allpkt_en allm_en mac_admask 0 mac_admask 1 01_80_c2_00_00_01 fwdpause_en pause frame type=88_08 op=00_01 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 278 section 9: ethernet macs document 1250_1125-um100-r there are five components to the filter. 1 broadcast packet detection. broadcast packets are either all accepted or all rejected. 2 exact match. the incoming packet address is compared to eight addresses (which may be unicast or multicast addresses), if it matches any of them then the packet is accepted, otherwise it is rejected. in parts with system revision periph_rev3 or greater two of the addresses have masks associated with them, if a bit is clear in the mask it is excluded from the comparison. the sense of this section of the filter can be reversed, so that packets will only be accepted if it does not match any of the addresses. all exact match addresses are always enabled, if less than 8 entries are needed the extra ones can be written with copies of one of the accepted addresses, or with 00-00-00-00-00-00 which is not a valid address. 3 hash match. nine bits are extracted from the partial crc of the packet for the six destination address bytes, this provides a hash value. this value is extracted from the standard crc-32 described in table 160 on page 268 . there are eight 64-bit hash table registers, these are concatenated to form a 512 bit bitmap (map bit 511 is hash_table7 bit 63... map bit 0 is hash_table0 bit 0). the hash value is used as an index into this bitmap, the packet is accepted if the bit is set and rejected if the bit is clear. the sense of the match can be inverted so the packet will only be accepted if the bit is clear. 4 multicast match. the filter can be configured to accept all multicast packets. if this is enabled then the only reason to put multicast addresses in the exact match filter or enable multicast hash matches is to make use of the match_exact and match_hash flags in the dma status information. 5 pause frame. if the header of the frame indicates that it is a pause frame (flow control frame) then it will normally be consumed by the interface and the transmitter flow controlled as requested. in parts where the system revision indicates periph_rev3 or greater if the fwdpause_en control is enabled then the hardware will not act on pause frames and the address filter will accept them for reception. if the destination address of the packet is accepted by any of the three filters or the promiscuous mode bit is set then the packet will be received. if there is no match then the packet is dropped. (note that the filter will not operate properly if the fifo release threshold rx_rl_thrsh is set smaller than the position required for the packet header, since the threshold has a minimum of two this is only a concern when there is a prepended header.) the receive address filter is controlled by the mac_adfilter_cfg register. there are a set of enable bits and invert bits to control the filter, as shown in figure 56 on page 277 . the address registers and hash map must also be written. a packet will be accepted if any of the filters indicate it should be accepted. if the broadcast address ff-ff- ff-ff-ff-ff is put in an exact match address register then broadcast packets will be accepted regardless of the state of the broadcast enable bit. however, setting the hash entry corresponding to the broadcast address will not cause acceptance because a hash match is qualified by the packet being unicast or multicast. the receive address filter is still applied in packet fifo mode. since the data is not expected to be formatted as an ethernet frame most applications will need to set the allpkt_en bit to accept all packets. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 279 the value for the hash filter for a particular ethernet address may be computed using the mchash macro and standard crc generator given in the following code: /******************************************************************** * eth_hwcrc32(buf,len) * * calculate a crc-32 of the specified bytes. this is used to * generate the masks for the hash filter on the receive side. * for the hash filter the bits must be swapped to match the hardware * * input parameters: * buf - buffer * len - length of buffer * return value: * crc as held in mac hardware *********************************************************************/ #define mchash(mca) ((eth_hwcrc32(mca, enet_addr_len) >> 1) & 0x1ff) static unsigned eth_hwcrc32(unsigned char *databuf,int datalen) { unsigned int idx, crc = 0xfffffffful, tmp; static unsigned int crctab[] = { 0x00000000, 0x1db71064, 0x3b6e20c8, 0x26d930ac, 0x76dc4190, 0x6b6b51f4, 0x4db26158, 0x5005713c, 0xedb88320, 0xf00f9344, 0xd6d6a3e8, 0xcb61b38c, 0x9b64c2b0, 0x86d3d2d4, 0xa00ae278, 0xbdbdf21c }; for (idx = 0; idx < datalen; idx++) { crc ^= *databuf++; crc = (crc >> 4) ^ crctab[crc & 0xf]; crc = (crc >> 4) ^ crctab[crc & 0xf]; } /********************************************* ** flip [31:0] to [0:31] to match hardware ** *********************************************/ tmp = 0; for (idx=0; idx<32;idx++) tmp |= ((crc< user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 281 the receive channel selection is used in the same way in packet fifo mode. in devices where the system revision indicates periph_rev3 or greater the 8 bit index into the channel number table can be formed from two four bit fields extracted from the packet. the split_ch_en bit in the mac_cfg register enables this feature. the lower 4 bits of the index are extracted from the packet at the offset specified by the {rx_ch_sel_msb,rx_ch_sel} value and the upper 4 bits of the index are extracted from the offset specified by the rx_ch_msn_sel field in the mac_adfilter_cfg register. both these are nibble offsets as described above. the rx_ch_msn_sel must point later in the packet, if rx_ch_msn_sel <= {rx_ch_sel_msb,rx_ch_sel} the channel selected is unpredictable. when split_ch_en is zero the rx_ch_msn_sel value is ignored and the upper 4 bits of the index are the nibble after the {rx_ch_sel_msb,rx_ch_sel} offset as described above. p acket t ype i dentification the receiver reads the ethernet packet type field in the inbound packet. some common packet types are detected and encoded in the status that is written to the descriptor. four of the types are fixed, the other four are programmable in the mac_type_cfg register. the packet type encodings are shown in table 163 . in packet fifo mode the 13th and 14th bytes of the received packet will be checked against the same values and the three bit encoding will be placed in the descriptor status word. in most cases this value should be ignored, but it is possible that the four configurable types could be used to identify special packets. table 163: ethernet type mappings ethernet type field status[57:55] encoding packet type 16?h0800 3?b000 ip v4 16?h0806 3?b001 arp <=1500 3?b010 802.3 length other 3?b011 no match mac_type_cfg[15:0] 3?b100 configurable types. mac_type_cfg[31:16] 3?b101 mac_type_cfg[47:32] 3?b110 mac_type_cfg[63:48] 3?b111 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 282 section 9: ethernet macs document 1250_1125-um100-r ip v 4 h eader c hecksum the receiver will check packets for an ipv4 header with no options and a correct header checksum. the iphdr_offset field in the mac_adfilter_cfg register sets the offset into the received packet that the header starts (this will normally be 15, since the ip header will start after the ethernet header, but it can be adjusted to allow encapsulation headers to be skipped). note that this offset is specified with the first byte in the destination address as 1. the first byte of the header must be 8?h45 indicating the ip version number is 4 and the header is the standard 5 (32 bit) words with no options. if this byte matches and the header checksum of the 5 words is correct (per rfc791) then the bad_ip4csbit will be clear in the status written back to the packet dma descriptor. if the bad_ip4cs bit is set, the packet may not be an ipv4 packet, it may have header options, or it may have an incorrect checksum. software must determine which of these is the case. note that the fast path of good packet, ethernet type ipv4, ipv4 header with no options and good checksum can be detected with an and mask and beq since all the status bits will be low in this case. the ipv4 header checksum is only computed in ethernet mode. in packet fifo mode the bad_ip4cs bit will always be set. tcp c hecksum c hecking the receiver will check packets for a valid tcp checksum. the result of this check is only valid if the ipv4 header checksum is correct. the iphdr_offset (described in the previous section) is used to locate the start of the ip header. the pseudo-header containing the source and destination ip addresses, ip protocol type and tcp length (ip length-20) is summed then the checksum continues for the tcp length of the packet (padded with a byte of 0 if required). the bad_tcpcs flag (written back to the b portion of the descriptor) will be set if the checksum is not 16'hffff. the same pseudo-header and checksumming algorithm is used for udp as tcp (the udp header itself is slightly different but since the header is included in the checksum this does not matter). the checksum is optional in udp so if the bad_tcpcs flag is set then software must check for a packet without checksum (the field is zero) before rejecting the packet. the tcp checksum is only computed in ethernet mode. in packet fifo mode the bad_tcpcs flag will be unpredictable. p ackets d ropped by the dma c hannel a packet will be dropped by the dma channel for one of three reasons: 1 the channel is disabled. 2 the channel is enabled but has no descriptors to receive the packet into. 3 the drop bit is set for the channel (for example if one of the dma channels is used for best effort traffic, that channel may have its drop bit set, so during overload no best effort packets are delivered to the system). in devices with system revision indicating periph_rev3 or greater the receive channel provides a counter in the dma_oodpktlost register that records the number of times a packet was lost and the channel was out of descriptors. the count is incremented every time a pack et is received and the channel is out of descriptors, the other state of the channel is not factored in. thus the count will still be incremented if the channel is disabled and out of descriptors when a packet is received. and it will be incremented if the drop bit is set and the channel is out of descriptors when a packet is received. but the count will not be incremented if there are descriptors available and the packet is dropped because the channel is disabled or the drop bit set. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 283 f low c ontrol the mac supports flow control in both full-duplex and half-duplex modes. in full-duplex mode pause frames are used to request the peer to stop sending for a particular length of time. in half-duplex mode back-pressure is applied by forcing the physical layer into not allowing transmissions. flow control can be explicitly invoked by setting the fc_sel bit in the mac_cfg register, or it can be requested automatically by the interface when the number of receive dma buffers falls below the low watermark (see section: ?descriptor count watermarks? on page 157 ). flow control is invoked if any of the sources request it. the flow control method used when the interface is unable to accept data is set by the fc_cmd field in the mac_cfg register, as shown in table 164 . if the interface is operating in half-duplex mode and flow control is invoked back pressure will be applied. if the fc_cmd field is set to 2'b01 back pressure is generated by the collision method. the interface forces collisions on the link by transmitting the collision data pattern. if the carrier is not currently being detected, or the protocol engine has not yet received more than the number of bytes set in the ifg_rx field of the mac_frame_cfg register then the collision transmission begins immediately. if more than the threshold number of bytes have been received in the current packet the collision will not be forced until after the incoming packet has completed (to avoid a late collision). packet transmission is still possible when back pressure is applied in this way. if there is an outgoing packet it will contend for access in the usual manner. if the transmitter gains the link then the packet can be sent normally, if it loses then the back pressure machine will cause collisions with the packet that another source is trying to send. in half-duplex mode if fc_cmd is set to 2'b10 the interface will apply back pressure by causing a false carrier sense. this is done by sending the collision data pattern (i.e. generating a carrier) after only 1/3rd of inter-frame gap time has elapsed since the carrier was last detected. this causes all other sources to sense a carrier and backoff. the carrier must be continually generated to ensure the other stations continue to detect it, so it is not possible to transmit packets while using this method. if the interface is operating in full-duplex mode, flow control is applied by transmitting a pause frame. a frame is created with the pause count (the number of slot times that the peer should not transmit) set to the value encoded in the tx_pause_cnt field in the mac_cfg register. when a pause is requested the slot times are also counted locally. towards the end of the period if the interface can still not accept packets an additional pause frame will be sent, requesting another pause in transmission by the peer. if flow control is no longer needed because dma buffers have been added or the fc_sel bit has cleared, or if flow control is disabled by the fc_cmd field being set to 2'b00, then a pause frame is immediately sent with a zero pause count to restart the peer. table 164: back pressure methods in half-duplex operation fc_cmd half-duplex back pressure method 2'b00 disabled 2'b01 force collision 2'b10 false carrier 2'b11 reserved bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 284 section 9: ethernet macs document 1250_1125-um100-r in full-duplex mode the reception of a valid pause frame always suspends transmission at the end of the packet currently being sent, transmission will be resumed after the requested pause time unless another flow control packet is received. pause frames will be detected if their destination address matches the address in the mac_ethernet_addr register or the multicast address 01-80-c2-00-00-01 and the packet type matches the mac control type (88_08) and he pause frame opcode (00_01) is found. normally valid pause frames will be consumed by the mac and not delivered to the dma engine. however in some situations (for example where a system requires that high priority traffic ignore the flow control) it is useful for the pause frame passed to the software (which could disable the low priority dma channel and keep the high priority one active). on devices with the system revision indicating periph_rev3 or greater the fwdpause_en bit can be set in the mac_adfilter_cfg register to cause the hardware to pass pause frames to the dma engine instead of acting on them. hardware response to pause frames is normally done at the mac level. this ensures that transmission stops as soon as possible. on devices with the system revision periph_rev3 or greater the flow control may be performed in the dma engines allowing each dma channel to either obey or ignore the directive. since there may be packets queued in the transmit fifo (up to 1kb of data between the dma engine and mac) there is a longer round-trip for the flow control loop in this case. the ch_base_fc_en bit must be set in the mac_vlantag register to enable channel based flow control. once this bit has been set if the fc_pause_en bit is set in the dma_config1 register for a channel then it will pause on flow control, otherwise it continues to transmit even when flow control is requested. on devices with the system revision periph_rev3 or greater when the fwd_pause_en bit is clear and hardware is acting on the pause frame the current pause state can be read from the tx_pause_on bit in the mac_status register, this bit will be set if the mac is still in the pause interval set by the previous pause frame. there are a number of ways pause frames can be ma naged. the standard one is to have the mac act on them and consume them. alternatively, the dma engine can act on them and stop only one channel. or they are passed to software and the hardware will not respond to them. note that in an entirely software controlled flow control system the cpu_pause_en bits in the dma_config1 register can be used to pause dma channels, but that the control loop will be much longer than having hardware act on the pause frames. a mix of software and hardware may be best, for example if channel based flow control is being used the dma engine can be configured to stop both channels on receipt of a pause frame but software can poll the tx_pause_on bit and may choose to release one of the channels. table 165: pause frame options fwdpause_en ch_base _fc_en ch 0 fc_pause_en ch 1 fc_pause_en description 0 0 x x standard operation. the mac will pause on receipt of a pause frame and will consume the frame. 0 1 0 0 ignore pause frames. the pause information is given to the dma engine but is applied to neither channel. 0 1 1 0 pause only channel zero. the pause information is given to the dma engine but is only applied to channel 0. 0 1 0 1 pause only channel one. the pause information is given to the dma engine but is only applied to channel 1. 0 1 1 1 pause both channels. the pause information is given to the dma engine and is applied to both channels. the standard operation setting will achieve the same result with a shorter flow control loop time, so this setting is only likely to be used in systems that switch between it and selective channel pause. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 285 if the interface is operating in 8 or 16 bit encoded packet fifo mode (see section: ?8-bit packet fifo operation? on page 293 and section: ?16-bit packet fifo operation? on page 298 ) the flow control is invoked by asserting the rxfc signal. in all other packet fifo modes flow control is ignored. i nterrupts there are two methods of signalling interrupts from the ethernet and packet fifo interface. the standard method uses a single system interrupt for all dma and management interrupts, the split method uses a special interrupt for dma channel 1 and the standard interrupt covers channel 0 and management. the mac_status register contains the status information for a mac. the low 32 bits contain the receive and transmit status for each of the dma channels, the upper bits contain error and rmon counter information. there is a mask register mac_int_mask associated with the status register. if a bit is set in both the mask and status then an interrupt will be raised. reads to the mac_status register have the side effect of clearing latched interrupt information. the information in the status register may be read with no side effects through the mac_status_debug register. the split_ch1 bit in the mac_int_mask register is used to select between the standard and split methods of signalling and clearing interrupts. it defaults to 0 to give the standard behaviour. s tandard i nterrupt s ignaling in the standard mode the main interrupt for the mac is raised whenever any status bit is set and the corresponding mask bit is set. reads from the mac_status register will clear all latched bits. s plit i nterrupt s ignaling in the split mode the main interrupt for the mac is raised whenever any channel 0 dma status bit (from bits 23:16, 7:0) is set and the corresponding mask bit is set, or when any error status bit (from bits 46:40) and corresponding mask bit is set. reads from the mac_status register will clear all latched bits associated with channel 0 or errors. the channel 1 interrupt for the mac will be raised if any channel 1 dma status bit (from bits 31:24,15:8) is set and the corresponding mask bit is set. reads from the mac_status1 register will clear all latched bits associated with channel 1. 1 x x x software pause frames. the pause frame will be received by software which may use the cpu_pause_en bit to pause channels, or may use it to cause discard from or reordering of internal queues. note that the interrupt service latency will be part of the flow control loop time, so the link peer will need larger buffers. table 165: pause frame options (cont.) fwdpause_en ch_base _fc_en ch 0 fc_pause_en ch 1 fc_pause_en description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 286 section 9: ethernet macs document 1250_1125-um100-r m anagement i nterface to phy there is a simple serial management interface between the mac and the phy device (or devices). it supports up to 32 phy chips (although some phy devices attach special meaning to address 0) each of which have 32 16-bit registers. the cpu runs the serial protocol through reading and writing the mac_mdio register. the management data clock (mdc) is generated by the interface and is an input to the phy. data written to the mdc bit in the mac_mdio register is put out on the mdc pin. the management data i/o line (mdio) can be driven by either the mac or the phy. it should have an external 1.5k pull-up resistor to pull the line to a 1 when neither is driving. the state of the pin can always be read on the mdio_in bit in the mac_mdio register. the interface can drive the line by clearing the mdio_dir bit and writing the data to output to the mdio_out bit. the mdio data is latched by the phy on the rising edge of mdc, so the mdio_dir and mdio_out bits should never be changed when the mdc bit is changed from a zero to a one. to send data to the phy the mdio_dir bit should be cleared, a single write to the mac_mdio register can be used to set mdc low and put the data on mdio_out. the same data should be written to mdio_out when mdc is set high. there is a general purpose output pin (geno) associated with each mac that is also controlled through the mac_mdio register. this pin is not part of the standard g/mii connection. each mac interface has its own set of mdio/mdc/geno pins. this allows the mac drivers to be completely independent with no shared resources, which works well in designs where the macs are partitioned across the processors with each running its own operating system. in a system running a single operating system (or where all the macs are controlled from a single driver) the phy addressing scheme can be used to attach the phys for all three macs to the mdio/mdc lines of a single mac. in this case the other mdc lines become available as general outputs, and the other mdio lines as gpios. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 287 figure 59 shows the flow for the main loop for sending and reading bits. figure 59: mdio flows single write to mac_mdio mdc = 0 mdio_out = bit to send mdio_dir = 0 wait half clock cycle time single write to mac_mdio mdc = 1 mdio_out = bit to send mdio_dir = 0 wait half clock cycle time more to send? single write to mac_mdio mdc = 0 mdio_dir = 1 write bits no ye s single write to mac_mdio mdc = 1 mdio_dir = 1 wait half clock cycle time single write to mac_mdio mdc = 0 mdio_dir = 1 wait half clock cycle time read bit from mdio_in read bits more to read? no ye s bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 288 section 9: ethernet macs document 1250_1125-um100-r the management protocol is shown in table 166 . this shows the two sides of the read (the mac request and the phy reply) and the full sequence sent by the mac for a write. bits are marked z where the line is not being driven. bits marked a form the five bit address of the phy that the mac is directing the command to (typically the phy chip will have some input pins to set the address it responds to). the bits marked r form the five bit register address. the bits marked x are the transfer of the 16 bits being read or written. the two addresses and data are sent most significant bit first. some phy devices can signal interrupts when the link status changes. these may be connected through one of the gpio pins. rmon c ounters each mac has 32 rmon statistics gathering registers. they are all 32 bits wide except the byte counts which are 64 bits wide. zeros will be read in the top 32 bits if a 64 bit access is made to the 32 bit registers, so software can treat them as all being 64 bit except for computing overflow. the registers may be cleared by software writing 0 to them. the counters must be written when the interface is initialized, until a write has been performed their behavior will be unpredictable. a write of any value other than zero will set the counter to that value and it will increment from there. if any counter overflows it will wrap to zero and continue to count. the cntr_ovrfl_err bit is set and the counter number is written to the counter_addr field in the mac_status register. the rmon counters are only updated in ethernet mode. table 166: mac to phy management protocol protocol idle start op code device addr register addr turn around data idle read (mac) idle 01 10 aaaaa rrrrr zz zzzz zzzz zzzz zzzz idle read (phy) idle zz zz zzzzz zzzzz z0 xxxx xxxx xxxx xxxx idle write (mac) idle 01 01 aaaaa rrrrr 10 xxxx xxxx xxxx xxxx idle write (phy) idle zz zz zzzzz zzzzz zz zzzz zzzz zzzz zzzz idle table 167: rmon counters number ( offset from 00_1006_0000 ) counter description 0 _0 - +4000 _1 - +5000 _2 - +6000 tx byte counter this counter counts the total number of bytes successfully transmitted by the mac. all bytes in the frame from the first destination address byte to the last crc byte are included in the count. successful transmission of a packet is defined by transmission of a packet without any errors such as collision, underrun or detection of invalid byte valid in control field of fifo. this is a 64 bit count. 1 _0 - +4008 _1 - +5008 _2 - +6008 tx collision counter this counter counts the total number of collisions experienced by the mac since the counter was last cleared. the count includes late collisions and will increment by 16 on an excessive collision. 2 _0 - +4010 _1 - +5010 _2 - +6010 tx late col. counter this counter counts the total number of late collisions experienced by the mac since the counter was last cleared. 3 _0 - +4018 _1 - +5018 _2 - +6018 tx ex. col. counter this counter counts the total number of excessive collisions experienced by the mac since the counter was last cleared. an excessive collision is defined as 16 consecutive collisions during the attempt to transmit a particular packet. the mac will abort the packet transmission when it suffers excessive collisions. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 289 4 _0 - +4020 _1 - +5020 _2 - +6020 tx fcs error counter this counter counts the total number of packets transmitted by the mac with fcs error. this can only happen when mac is not appending the crc to the transmitted packet. the mac checks the crc on all transmitted packets and flags all packets with fcs errors. 5 _0 - +4028 _1 - +5028 _2 - +6028 tx abort error counter this counter counts the total number of packets which were aborted during transmission. transmission can be aborted by a fifo underrun. 6reserved 7 _0 - +4038 _1 - +5038 _2 - +6038 tx bad packet counter this counter counts the total number of bad packets transmitted by the mac. bad packets are those packets which are not successfully transmitted. a packet which experienced late collision or excessive collision or is aborted by mac during its transmission is considered bad packet. 8 _0 - +4040 _1 - +5040 _2 - +6040 tx good packet counter this counter counts the total number of successfully transmitted packets. 9 _0 - +4048 _1 - +5048 _2 - +6048 tx runt packet counter this counter counts the total number of runt packets (packets smaller than the minimum frame size) transmitted by the mac. the minimum frames size for ieee 802.3 compliance is 64 bytes, if a different minimum frame size has been set in the mac_frame_cfg register then runt packets will be any packet smaller than that number. 10 _0 - +4050 _1 - +5050 _2 - +6050 tx over size packet counter this counter counts the total number of oversize packets (packets larger than the maximum frame size) transmitted by the mac. the maximum frames size for ieee 802.3 compliance is 1518 bytes, if a different maximum frame size has been set in the mac_frame_cfg register then oversize packets will be any packet larger than that number. 11 reserved 12 reserved 13 reserved 14 reserved 15 reserved 16 _0 - +4080 _1 - +5080 _2 - +6080 rx byte counter this counter counts the total number of bytes received by the mac regardless of the status of a packet (good or bad, as defined below). this is a 64 bit count. 17 _0 - +4088 _1 - +5088 _2 - +6088 rx multicast packet counter this counter counts the total number of packets received by the mac with a multicast destination address (broadcast packets are not counted). 18 _0 - +4090 _1 - +5090 _2 - +6090 rx broadcast packet counter this counter counts the total number of packets received by mac with the broadcast destination address. 19 _0 - +4098 _1 - +5098 _2 - +6098 rx bad packet counter this counter counts the total number of bad packets received by the mac. bad packets are those packets which have at least one of the following errors: fcs error length error dribble error (only in 10/100 mbp/s) code error runt packet error oversize packet error table 167: rmon counters (cont.) number ( offset from 00_1006_0000 ) counter description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 290 section 9: ethernet macs document 1250_1125-um100-r 20 _0 - +40a0 _1 - +50a0 _2 - +60a0 rx good packet counter this counter counts the total number of good packets received (packets with no errors) by the mac. 21 _0 - +40a8 _1 - +50a8 _2 - +60a8 rx runt packet counter this counter counts the total number of runt packets (packet smaller than the minimum frame size) received by the mac. the minimum frames size for ieee 802.3 compliance is 64 bytes, if a different minimum frame size has been set in the mac_frame_cfg register then runt packets will be any packet smaller than that number. 22 _0 - +40b0 _1 - +50b0 _2 - +60b0 rx over size packet counter this counter counts the total number of oversize packets (packets larger than the maximum frame size) received by the mac. the maximum frames size for ieee 802.3 compliance is 1518 bytes, if a different maximum frame size has been set in the mac_frame_cfg register then oversize packets will be any packet larger than that number. 23 _0 - +40b8 _1 - +50b8 _2 - +60b8 rx fcs error packet counter this counter counts the total number of packets received by the mac with an fcs error (i.e. a bad crc). 24 _0 - +40c0 _1 - +50c0 _2 - +60c0 rx length error packet counter this counter counts the total number of packets received by the mac with length error (where the actual number of bytes received did not match the length given in the ethernet header). 25 _0 - +40c8 _1 - +50c8 _2 - +60c8 rx code error packet counter this counter counts the total number of packets received by the mac that had a code error signalled by the phy. 26 _0 - +40d0 _1 - +50d0 _2 - +60d0 rx dribble error packet counter this counter counts the total number of packets received by the mac with a dribble error. a dribble error (also referred to as an alignment error) is when a packet is received that does not contain an integral number of bytes. this counter is not used for 1000 mbp/s operation. 27 reserved 28 reserved 29 reserved 30 reserved 31 reserved table 167: rmon counters (cont.) number ( offset from 00_1006_0000 ) counter description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 291 p acket fifo i nterfaces in addition to the standard ethernet mode, the network interfaces can be put into packet fifo mode. in this mode the ethernet protocol processing is disabled and the pins are used to provide a simple interface with either an 8-bit or 16-bit data path each way. the packet fifo interface can be clocked at up to 208 mhz or higher (subject to part speed grade, for full details refer to the hardware data sheet). as can be seen in figure51onpage264 the packet fifo engine sits to the side of the ethernet mac unit, but most of the network interface logic is common to the ethernet and packet fifo modes. the same dma controller is used to move data between the packet interface and memory. there are several modes of packet fifo operation, these select the data width and method of framing packets. the minimum packet size supported in the packet fifo modes is 10 bytes, using smaller packets than this will have unpredictable results. the maximum packet size that will be correctly reported is 16k - 1 bytes (because of the field width in the dma descriptor) however the interface does not impose a maximum and will continue receiving as long as there are dma descriptors available. the 8-bit packet fifo modes simply replace the ethernet mac with the simpler packet fifo logic. the data pins remain the same and the data valid (rxdv, txen) and error (rxer, txer) pins are used to signal framing information. in addition in the encoded mode the collision (col) and management data (mdio) pins get used to provide flow control on the link. switching between ethernet and any 8-bit packet mode only affects the interface being switched, so there can be any mix of ethernet and 8-bit packet interfaces. the 16-bit packet fifo modes do a larger re-configuration of the pins. the data sheet gives the mapping from the ethernet use to the 16-bit mode uses of the pins. interface 1 does not support 16-bit modes, the system behavior will be undefined if it is configured for 16-bit operation. the reuse of pins causes some restrictions on the configurations that can be supported when 16-bit packet fifo mode is used. if interface 0 is put in 16- bit packet fifo mode then interface 1 may not be used. if interface 2 is put in 16-bit packet fifo mode then interface 1 may not be used, and interface 0 can only be used in a packet fifo mode. on the BCM1125/h the interfaces may be configured as two 8-bit interfaces or a single 16 bit interface. the valid combinations for a bcm1250 are: interface 0 in 16-bit packet mode, interface 1 disabled, interface 2 in ethernet mode. interface 0 in 16-bit packet mode, interface 1 disabled, interface 2 in 8-bit packet mode. interface 0 in 16-bit packet mode, interface 1 disabled, interface 2 in 16-bit packet mode. interface 0 in 8-bit packet mode, interface 1 disabled, interface 2 in 16-bit packet mode. table 168: BCM1125 ethernet/fifo pin usage e0_ pins e1_ pins all interfaces ethernet or 8-bit fifo gmii or 8 bit fifo e0_ gmii or 8-bit fifo e1_ one 16-bit packet fifo 16-bit packet fifo f_ bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 292 section 9: ethernet macs document 1250_1125-um100-r the pin mapping is summarized in the following table: other than the external data width and framing options (described below) the packet fifo modes use the same internal data path. the following rules/differences apply in all modes. the speed selection in the mac_cfg register must be set for gigabit operation to use the reference input clock to generate the transmit clock. the ipv4 header checking is not performed. the iphdr_offset field in the mac_adfilter_cfg register is not used and should be set to zero. the address filter is not normally useful in packet fifo mode and can be configured to accept all packets by setting the allpkt_en bit in the mac_adfilter_cfg register. the 13th and 14th bytes of the incoming packet are still compared as if they contained an ethernet type and the dma status word in bits [57:55] will still be set as described in section: ?packet type identification? on page 281 . if the bypass_fcs_chk bit is set in the mac_cfg register then received packets will have their final four bytes checked for a valid crc-32 (using the same algorithm as for the ethernet) and the bit in the receive dma status word will be set accordingly. if the bypass_fcs_chk bit is clear the status bit will always indicate the crc check passed. the receive channel selection is done in the same way as for the ethernet mode as described in section: ?receive dma channel selection? on page 280 . the only transmit options (see section: ?data buffers and descriptors? on page 147 and table 107 on page 173 ) that can be used in the start of packet descriptor are no modification (4?b0111) and append crc (4?b001). all other options will give unpredictable results. some modes of the packet fifo interface allow packet errors to be signalled. these packets will be marked as bad in the receive dma status information. the automatic discard of error packets (described in the section: ?receiver configuration? on page 274 ) should be disabled in packet fifo modes. the rmon counters are not incremented when the interface is in packet fifo modes. table 169: bcm1250 ethernet/fifo pin usage e0_ pins e1_ pins e2_ pins all interfaces ethernet or 8-bit fifo gmii or 8-bit fifo e0_ gmii or 8-bit fifo e1_ gmii or 8-bit fifo e2_ one 16-bit packet fifo, one ethernet or 8-bit fifo 16-bit packet fifo f0_ gmii or 8-bit fifo e2_ two 16-bit packet fifos 16-bit packet fifo f0_ 16-bit packet fifo f1_ one 16-bit packet fifo, one 8-bit packet fifo 8-bit fifo e0_ 16-bit packet fifo f1_ user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 293 flow control in encoded packet fifo modes flow control is available in the encoded packet fifo modes. in addition to the dma descriptor based flow control there is a link level flow control. the transmitter can be controlled by the col input in 8 bit mode and the txfc input in 16 bit mode (note that these are the same physical pin). since the input is synchronized internally there is some uncertainty in the number of additional bytes that can be transmitted follow ing assertion of the flow control signal. the transmitter will stop: 2-4 cycles after txfc assertion in 16 bit mode no crc (4-8 bytes) 2-6 cycles after txfc assertion in 16 bit mode + crc (4-12 bytes) 2-4 cycles after txfc assertion in 8 bit mode no crc (2-4 bytes) 2-8 cycles after txfc assertion in 8 bit mode + crc (2-8 bytes) the receiver will assert its flow control output (mdio in 8 bit mode, rxfc in 16 bit mode) either because the dma watermark state requests flow control or to prevent the receive fifo overflowing. the enc_fc_thrsh field in the mac_thrsh_cfg register sets the flow control threshold. flow control will be requested when there are fewer than this number of doublewords free in the fifo . there is a 1 cycle delay from the number of entries in the fifo falling below the threshold and the external signal being asserted, and there can be up to 10 cycles of data (10 bytes in 8 bit mode, 20 bytes in 16 bit mode) in flight between the receive data pins and the fifo. as an example consider connecting two parts back-to-back. with the default threshold of 4 double words (32 bytes) in 16 bit mode there can be 22 bytes (2 from the one cycle delay and 20 in flight) added to the receive fifo if the transmitter stopped instantaneously. however, there is additional delay. if crcs are not being appended by the transmitter an additional 8 bytes could be sent, leaving two bytes margin. but if the transmitter was appending crc then the additional 12 bytes would cause the receive fifo to overflow, so the threshold must be increased to 5 doublewords. note that the direction of the mdio/rcfc pin is controllable by software using the mdio_dir bit in the mac_mdio register. this must be set for output (which is the default) when receive flow control is being used. 8-b it p acket fifo o peration there are two models for running the packet fifo. in the packet model start of packet (sop) and end of packet (eop) data are flagged and all data between these marks are counted as a single packet and passed through the dma engine in the same way an ethernet packet would be. in this packet based model once a sop has been seen further sop signals are ignored until an eop has been triggered. the second model is to have an unframed data stream, in this case the dma will run through filling dma buffers in sequence for as long as there are descriptors available. the receive filtering options are described in section: ?packet fifo interfaces? on page 291 . if an unframed data stream is being received software must ensure that the mac_chup and mac_chlo tables select the same dma channel at all indices. packets transmitted in any of the modes can have a crc-32 appended by setting the append crc bit in the transmit packet descriptor. packets received have their final four bytes checked for a valid crc-32 and if the bypass_fcs_chk bit is set in the mac_cfg register the status bit in the receive descriptor will be set accordingly (if the bypass_fcs_chk bit is clear the status word will never flag a crc error). if the crc-32 is used on the receive side there must be at least seven clock cycles between the end of packet and the start of the next packet. if this inter-frame gap is not provided then the crc checker will give unpredictable results. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 294 section 9: ethernet macs document 1250_1125-um100-r there are four formats that are available for the 8 bit packet fifo to signal data validity and packet boundaries. in all cases data and control signals are sampled on the rising edge of the clock. on the transmit side the gmii txen (enable) and txer (error) signals are used as two control signals that are used to send out the framing information, and on receive the rxdv (data valid) and rxer (error) pins are used to receive the framing information. 8-b it gmii s tyle p acket fifo the gmii style of packet fifo mode is shown in figure 60 on page 294 . the packet data is framed by the txen or rxdv signal. the first byte that has it active is marked as the start of a packet and the last byte that has it active is the end of the packet, all bytes between are valid and part of the packet. the txer or rxer signal can be used to signal an error whenever the frame signal is active. figure 60: 8-bit packet fifo gmii style the error pin txer/rxer may be used to signal that a packet has an error. it should be asserted when the error is detected and remain high until the enable signal falls. txen/rxdv txer/rxer txd/rxd[7:0] tclko/rclk 55 table 170: codes for gmii packet fifo mode txen / rxdv txer / rxer valid data, start of packet 0->1 at start of cycle 0 valid data 10 valid data, end of packet 1->0 at end of cycle 0 error 1 1 held until txen/rxdv falls user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 295 8-b it e ncoded p acket fifo encoded mode, shown in figure 61 , uses the control lines to signal the four states that can be associated with the data. this mode should be used for packet data where there can be invalid bytes between the start and end of packet marks. table shows the encodings used. figure 61: 8-bit packet fifo encoded style in this mode flow control is provided in each direction. transmit flow control is input on the col pin (normally the collision sense from the phy), when this is asserted the interface will stop sending data (and drive the data not valid control code) two rising clock edges later. the interface will assert the mdio pin (normally the management interface to the phy) as a receive flow control output if (a) the cpu sets the force flow control configuration bit; (b) the number of descriptors on a receive channel falls below the low watermark and automatic flow control is enabled for that channel; or (c) there are less than 4 64 bit words left free in the receive fifo. if the device the other end of the link honours the flow control request within a few clock times data will never be lost on the link. in this mode a transmit fifo underflow during transmission of a packet causes bubbles to be inserted in the data stream (the data not valid code will appear during a packet) but transmission will not be aborted. (in all other modes a transmit fifo underrun causes the packet to be aborted). txen/rxdv txer/rxer txd/rxd[7:0] tclko/rclk 55 sop eop table 171: codes for 8-bit encoded bypass mode txen / rxdv txer / rxer valid data, start of packet 10 valid data 11 valid data, end of packet 01 data not valid 00 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 296 section 9: ethernet macs document 1250_1125-um100-r 8-b it sop f lagged p acket fifo sop flagged packet fifo mode uses one control line as a data valid signal and the other to flag start of packet. the end of packet is one cycle before the sop or whenever the data goes invalid (this extra eop is required to push out the last data at the end of a valid sequence). figure 62: 8-bit packet fifo sop style txen/rxdv txer/rxer txd/rxd[7:0] tclko/rclk 55 sop eop sop eop table 172: codes for 8-bit sop packet fifo txen / rxdv txer / rxer valid data, start of packet 11 valid data 10 valid data, end of packet 1 next cycle 1 1->0 at end of cycle anything data not valid 0anything user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 297 8-b it eop f lagged p acket fifo eop flagged packet fifo mode uses one control line as a data valid signal and the other to flag end of packet. the start of packet is one cycle after an end of packet, or the first data after the valid signal has risen. any sops that occur between an sop and eop are ignored, so in figure 63 there is not an sop flagged in the cycle marked x, one cycle after txen/rxdv was low. this mode is good for streaming data that uses only the data valid signal. if the eop flag is always low the interface will transfer a single never-ending packet for as long as dma buffers are provided. figure 63: 8-bit packet fifo eop style txen/rxdv txer/rxer txd/rxd[7:0] tclko/rclk 55 sop eop sop x table 173: codes for 8-bit eop bypass mode txen / rxdv txer / rxer valid data, start of packet 0->1 at start of cycle anything 1 1 previous cycle valid data 10 valid data, end of packet 11 data not valid 0anything bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 298 section 9: ethernet macs document 1250_1125-um100-r 16-b it p acket fifo o peration the 16-bit packet fifo mode provides an interface that can run bidirectionally at oc-48 data rates. it can externally be converted into a pos-phy level 3 interface using a simple gearbox pld or fpga. alternatively, it may be connected directly to an asic. on the bcm1250, there are two packet fifo interfaces . on the BCM1125/h there is one. interface f0 (f on the BCM1125/h) replaces the ethernet macs e0 and e1 , and reuses pins from both. it uses the dma controller associated with interface e0. on the bcm1250 packet interface f1 reuses pins from all three ethernet macs (e0, e1 and e2) and uses the dma engine associated with e2. it is possible to run the f0 packet interface along with the e2 ethernet interface. the receive filtering options are described in section section: ?packet fifo interfaces? on page 291 . if an unframed data stream is being received software must ensure that the mac_chup and mac_chlo tables select the same dma channel at all indices. packets transmitted in any of the packet fifo modes can have a crc-32 appended by setting the append crc bit in the transmit packet descriptor. packets received have their final four bytes checked for a valid crc- 32 and if the bypass_fcs_chk bit is set in the mac_cfg register the status bit in the receive descriptor will be set accordingly (if the bypass_fcs_chk bit is clear the status word will never flag a crc error). if the crc-32 is used on the receive side there must be at least three clock cycles between the end of packet and the start of the next packet. if this inter-frame gap is not provided then the crc checker will give unpredictable results. the 16 bit packet fifo mode uses three control signals that accompany the data and, in encoded mode, a flow control signal in the reverse direction. the 16 bit wide data path is treated as two bytes where the data on bits [7:0] is earlier in the packet (and therefore will be dmaed to/from a lower memory address) than the data on [15:8]. the last 16 bit half-word of a packet that is an odd number of bytes long will have valid data on bits [7:0] and an unpredictable value on bits [15:8]. 16-b it gmii s tyle p acket fifo the 16-bit gmii style of packet fifo interface is shown in figure 64 . the packet data is framed by the txc[0] or rxc[0] signal. the first byte that has it active is marked as the start of a packet and the last byte that has it active is the end of the packet, all bytes between are valid and part of the packet. the txc[1] or rxc[1] signal can be used to signal an error whenever the frame signal is active, it should be asserted when the error is detected and held high until the frame signal falls. figure 64: 16-bit gmii style packet fifo txc/rxc[0] txc/rxc[1] txc/rxc[2] txd/rxd[7:0] txd/rxd[15:8] tclko/rclk sop eop 55 sop 55 eop user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 299 txc/rxc[2] is used to indicate the validity of the upper 8-bits of data. it should be the same as txc/rxc[0] except for the final data in a packet that has an odd number of bytes. 16-b it e ncoded p acket fifo the 16-bit encoded packet fifo mode is shown in figure 65 . the txc[2:0] signals indicate the status of the data they accompany. the encoding is chosen to a llow easy conversion to and from pos-phy level 3 signalling, which is a wider slower packet bus. the flow control signal runs in the opposite direction to the data. figure 65 shows two packets being sent. in the first the sender is unable to supply data for one cycle and removed the valid signal. in the second packet the receiver asserts the flow control signal for a cycle requesting a pause from the sender. the transmitter will see the flow control request on the next rising edge of the clock and will send data for 2-4 cycles before suspending transmission one cycle later. the interface will assert its flow control output when receive channel flow control is invoked either by one of the dma channels having fewer descriptors than the low watermark or by an explicit processor request. figure 65: 16-bit encoded packet fifo table 174: codes for 16-bit gmii style packet fifo txc/rxc[2:0] data not valid 000 start of packet, 2 bytes valid 000->101 at start of cycle middle of packet, 2 bytes valid 101 end of packet, 1 byte valid 001->000 at end of cycle end of packet, 2 bytes valid 101->000 at end of cycle error 111, bit [1] held set until 000 txc/rxc[2:0] txd/rxd[7:0] txd/rxd[15:8] tclko/rclk txfc/rxfc 000 101 111 000 111 100 111 111 010 000 101 111 111 000 111 110 sop eop 55 sop 55 eop fc table 175: codes for 16-bit encoded bypass mode txc/rxc[2:0] data not valid 000 reserved 001 end of packet, 1 byte valid 010 end of packet with error 011 reserved 100 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 300 section 9: ethernet macs document 1250_1125-um100-r in this mode flow control is provided in each direction. transmit flow control is input on the tx_fc pin, when this is asserted the interface will stop sending data (and drive the data not valid control code) two rising clock edges later. the part will assert the rx_fc pin as a receive flow control output if (a) the cpu sets the force flow control configuration bit; (b) the number of descriptors on a receive channel falls below the low watermark and automatic flow control is enabled for that channel; or (c) there are less than four 64 bit words left free in the receive fifo. if the device the other end of the link honours the flow control request within a few clock times data will never be lost on the link. in this mode a transmit fifo underflow during transmission of a packet causes bubbles to be inserted in the data stream (the data not valid code will appear during a packet) but transmission will not be aborted. (in all other modes a transmit fifo underrun causes the packet to be aborted). r estrictions w hen r esetting the i nterface the mac and packet fifo logic is automatically reset when the part is reset. however, on bcm1250s prior to periph_rev3, correct reset of the logic requires that there be a few rising edges on refclk01 (for macs e0 and e1) and refclk2 (for mac e2) before software releases the interface from reset. this is not normally a problem since the clocks will be free running. if the clocks are not provided then the first access to the registers for the corresponding interface will place the zbbus in an undefined state. if an interface is not used there are two options: (1) ensure software never ac cesses the unused interface registers; (2) provide some edges on the reference clock before software can access the registers. clearly (2) is preferable, since otherwise a bug in the software (or even a debugger collecting the system state) could cause a hang that would be hard to track down. there is no need to provide a periodic clock. one possible solution would be to connect the unused refclk input to the boot rom chip select (o r scl if the system boots from smbus) since this is guarenteed to toggle when the part comes out of reset (before any instructions run the sb-1 will have fetched 16 bytes from the boot rom, thus there will be 4 (for a 32 bit rom) or 16 (for an 8 bit rom) edges on the refclk even in the unlikey case where the first instruction accesses the mac registers). the interface can also be reset by software. again, for parts prior to periph_rev3 the clock needs to be running for correct operation (note that if the clock was running during the chip reset and the mac is not being used then it is safe to perform a software reset without a clock). this can be done by setting the (self-clearing) p_reset bit in the mac_enable register. after this bit has been written with a 1, the software should delay for at least six times the clock period of the receive clock then write the bit with a 1 again. following the second write the interface will be fully reset. (if this sequence is not followed the interface will reset but it is possible for a junk packet to be received when the receiver is enabled again). before software resets the mac (or a dma channel) it should ensure that there is no outstanding dma activity (failure to do this can cause resources to be lost between the mac and zbbus and can degrade performance). the dma should be stopped by clearing the descriptor count by writing the complement of the current count into the count register (the hardware will add this value and discard the carry so the count will become zero), then reading any of the dma registers, then waiting for twice the transmission time of a maximum length packet (this ensures any in- progress transmission or reception has completed). once the dma has stopped the reset can be safely written. start of packet, 2 bytes valid 101 end of packet, 2 bytes valid 110 middle of packet, 2 bytes valid 111 table 175: codes for 16-bit encoded bypass mode txc/rxc[2:0] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 301 mac r egisters note all of the mac registers need to be initialized by software before it will function. the BCM1125/h has macs 0 and 1. accesses made to the address range allocated to mac 2 may cause all macs to exhibit unpredictable behavior. table 176: mac configuration registers mac_cfg_0 - 00_1006_4100 mac_cfg_1 - 00_1006_5100 mac_cfg_2 - 00_1006_6100 this register is used in both ethernet and packet fifo modes bits name default description 0 ss_tmode 1'b0 this bit must always be zero for normal operation (broadcom use only test bit). 1 tx_hold_sop_en 1'b0 when this bit is set the interface will retain the first few bytes of each transmitted packet in the transmit fifo. this enables the interface to automatically retry any packet that encounters an error during the initial part of its transmission. the tx_rl_thrsh parameter (in the mac_threshold register) sets the number of 64 bit fifo entries that are retained, once this number of entries have been successfully transmitted the fifo is unlocked and no data is retained. for example if tx_hold_sop_en is set and tx_rl_thrsh is set to 8, then if the mac detects a collision before 8 entries (64 bytes) are read from the transmit fifo, the fifo can be restored the start of the packet and the packet can be automatically retried. automatic retry can be triggered by any error that happens (collision, underrun error, excessive collision error, or late collision) while the fifo is in locked state. (i.e. less than the number of entries set by tx_rl_thrsh have been read from the transmit fifo for a given packet.). the retry_en, ret_drprep_en and ret_ufl_en bits enable automatic retry selectively for each of the error types. if the tx_hold_sop_en bit is clear or the number of entries set by tx_rl_thrsh have been read from the fifo then the fifo will be unlocked and automatic retry is not possible. in this case the packet with the error will be dropped. used in ethernet and packet fifo modes. 2 retry_en 1'b0 if this bit is set then automatic retry is enabled when collisions are detected (but not late or excessive collisions). the tx_hold_sop_en bit (bit [1]) must be set to allow automatic retry, see the description above for more details. used in ethernet and packet fifo modes. 3 ret_drpreq_en 1'b0 if this bit is set then automatic retry is enabled when late collisions or excessive collisions are detected. the tx_hold_sop_en bit (bit [1]) must be set to allow automatic retry, see the description above for more details. used in ethernet and packet fifo modes. 4 ret_ufl_en 1'b0 if this bit is set then automatic retry is enabled when a transmit fifo underflow is detected. the tx_hold_sop_en bit (bit [1]) must be set to allow automatic retry, see the description above for more details. used in ethernet and packet fifo modes. 5 burst_en 1'b0 this bit should be set to enable burst operation when the mac is running in 1000 mbp/s mode. burst mode enables transmission of multiple packets without releasing the network between them. used in ethernet mode only. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 302 section 9: ethernet macs document 1250_1125-um100-r 8:6 tx_pause_cnt 3'b0 transmit pause count. this field sets the number of slot times pause that will be requested when the interface transmits a pause frame. it is also used to initialize the local pause counter which indicates when the next flow control packet needs to be sent. the encodings are: 000: 512 001: 1k 010: 2k 011: 4k 100: 8k 101: 16k 110: 32k 111: 64k used in ethernet mode only. 16:9 reserved 8'b0 reserved 17 ap_stat_en 1'b0 append packet status enable. when this bit is set the packet status is written to the receive fifo following the last entry in the packet. this bit should be set for ethernet mode and clear for packet fifo mode. used in ethernet and packet fifo modes. 18 reserved 1'b0 reserved 19 drp_errpkt_en 1'b0 if this bit is set then automatic dropping is enabled for all error packets (bits [31:26] are ignored). used in ethernet mode only. 20 drp_fcserrpkt_en 1'b0 if this bit is set then packets with an fcs (crc) error are automatically dropped. used in ethernet mode only. 21 drp_codeerrpkt_en 1'b0 if this bit is set then packets that are signalled with a code error by the phy are automatically dropped. used in ethernet mode only. 22 drp_drblerrpkt_en 1'b0 if this bit is set then packets with a dribble error are automatically dropped. used in ethernet mode only. 23 drp_rntpkt_en 1'b0 if this bit is set then runt packets (those shorter than the minimum packet size configured in the mac_frame_cfg register) are automatically dropped. used in ethernet mode only. 24 drp_oszpkt_en 1'b0 if this bit is set then oversize packets (those longer than the maximum packet size configured in the mac_frame_cfg register are automatically dropped. (unless a non-standard protocol is used the maximum packet size will always be larger than the receive fifo, so this is not likely to happen in practice.) used in ethernet mode only. 25 drp_lenerrpkt_en 1'b0 if this bit is set then packets with a length error are automatically dropped. a length error is signalled when the length/type field of the packet is less than or equal to 1500 (indicating it is being used as the length) and its value does not match the packet length. used in ethernet mode only. 31:26 reserved 6'b0 reserved table 176: mac configuration registers (cont.) mac_cfg_0 - 00_1006_4100 mac_cfg_1 - 00_1006_5100 mac_cfg_2 - 00_1006_6100 this register is used in both ethernet and packet fifo modes bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 303 32 bypass_sel 1'b0 when this bit is set the mac is bypassed and packet fifo mode is enabled. this provides a simple fifo interface, backed by the dma engine. see section: ?8- bit packet fifo operation? on page 293 for details. 33 hdx_en 1'b0 when this bit is set the mac will operate in half-duplex mode, when the bit is clear it will run full-duplex. the mac supports both full and half-duplex operation at all speeds. used in ethernet mode only. 35:34 speed_sel 2'b0 this field sets the speed the mac will operate. 00: 10 mbps - the tclk input should be 2.5 mhz. 01: 100 mbps - the tclk input should be 25 mhz. 10: 1000 mbps - the transmit clock will be supplied by the interface. the reference clock input should be 125 mhz. 11: reserved used in ethernet mode only. must be set to 10 for packet fifo modes. 36 tx_clk_edge 1'b0 this selects the edge of the transmit clock that is used to send the data. normally the rising clock edge should be used. the falling edge can be used to support old 10 mbps phy chips that require the full hold time specified in the original ieee specification. 0: the rising edge of the clock is the active one. 1: the falling edge of the clock is the active one. used in ethernet and packet fifo modes. 37 loopback_sel 1'b0 when this bit is set an internal loopback path is enabled, connecting the transmitter and receiver gmii pins. used in ethernet and 8 bit packet fifo modes. 38 fast_sync 1'b0 this bit must be set for normal operation. (it defaults to 0 so software should be sure to set it before starting the mac.) used in ethernet and packet fifo modes. 39 ss_en 1'b0 this bit must always be set. (broadcom use only debug bit). (it defaults to 0 so software should be sure to set it before starting the mac.) used in ethernet and packet fifo modes. 41:40 bypass_cfg 2'b0 this field sets the strobe signals that are used on both transmit and receive interfaces in packet fifo mode. 00: gmii style 01: encoded 10: sop flagged (not valid in 16 bit packet fifo mode) 11: eop flagged (not valid in 16 bit packet fifo mode) used in packet fifo modes. 42 bypass_16 1'b0 set for 16 bit packet fifo mode, clear for 8 bit packet fifo mode. the interface behavior will become undefined if this bit is set for mac 1. setting this bit for mac 0 will cause the pins to change from their eight bit e0 and e1 configuration to the 16 bit f0 configuration. setting this bit for mac 2 will cause the pins to change from their eight bit e0, e1 and e2 configuration to the 16 bit f1 configuration. this bit must be set to reflect the external connection. used in packet fifo modes. table 176: mac configuration registers (cont.) mac_cfg_0 - 00_1006_4100 mac_cfg_1 - 00_1006_5100 mac_cfg_2 - 00_1006_6100 this register is used in both ethernet and packet fifo modes bits name default description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 304 section 9: ethernet macs document 1250_1125-um100-r 43 bypass_fcs_chk 1'b0 if this bit is set then the interface will perform the fcs check on packets received in packet fifo mode. the last four bytes are checked for a valid crc-32 using the same algorithm as for ethernet. the status will be recorded in the receive dma descriptor status field. if this bit is clear no fcs check is done and all packets will be marked as having a correct crc. used in packet fifo modes. 44 rx_ch_sel_msb 1'b0 this is the top bit of rx_ch_sel (see bits 63:57). used in ethernet and packet fifo modes. 45 split_ch_sel 1'b0 system revision < periph_rev3: reserved system revision periph_rev3 or later: if this bit is set the 8 bit index used to select the receive channel number is made up from nibbles extracted from two different places in the packet, {rx_ch_sel_msb,rx_ch_sel} specify the offset of the lower 4 bits of the index, rx_ch_msn_sel (in the mac_adfilter register) specify the upper 4 bits. if split_ch_sel is zero then {rx_ch_sel_msb,rx_ch_sel} is used to select the low 4 bits of the index and the upper 4 bits is always the next nibble. used in ethernet and packet fifo modes. 53:46 bypass_ifg 8'b0 this field gives the number of clock cycles of inter-frame gap that is inserted in packet fifo mode. if the transmitter is set to append a crc then this field has a minimum value of 3 in 16 bit fifo mode and a minimum value of 7 in 8 bit fifo mode. if crcs are never inserted then packets may be transmitted back to back. used in packet fifo modes. 54 fc_sel 1'b0 this bit is used by software to force flow control. if it is set then flow control will be asserted on the link (pause frames in full duplex ethernet, backpressure by the method encoded in the fc_cmd bits for half duplex ethernet, or the link level flow control pin rxfc for encoded packet fifo mode). flow control will remain asserted until this bit is cleared. note that if this bit is set while the mac is disabled the results are unpredictable. used in ethernet and packet fifo modes. 56:55 fc_cmd 2'b0 this field sets the flow control style to be used for both software flow control (set by bit 54) and automatic flow control from the receive dma channels. this field is only used for half duplex links. 00: disabled 01: enabled using collisions 10: enabled using false carrier 11: unpredictable used in ethernet mode only. 63:57 rx_ch_sel 7'b0 this field along with the rx_ch_sel_msb bit sets the offset into received packets to extract 8 bits to select the receive dma channel. this offset is in nibbles. if bit [57] is zero then bits [44, 63:58] give the byte of the packet (starting from zero) that will be used to index the channel select table. if bit [57] is one then the top four bits of the byte indexed by [44, 63:58] will be used as the low four bits to index the channel select table, and the lower four bits from the next byte of the packet will be used as the upper four bits to index the channel select table. used in ethernet and packet fifo modes. table 176: mac configuration registers (cont.) mac_cfg_0 - 00_1006_4100 mac_cfg_1 - 00_1006_5100 mac_cfg_2 - 00_1006_6100 this register is used in both ethernet and packet fifo modes bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 305 table 177: mac enable registers mac_enable_0 - 00_1006_4400 mac_enable_1 - 00_1006_5400 mac_enable_2 - 00_1006_6400 this register is used in both ethernet and packet fifo modes bits name default description 1:0 rxdma_en 2'b0 receive dma channel enable. must be set to enable a channel. bit 0 corresponds to channel 0, bit 1 to channel 1. 3:2 reserved 2'b0 reserved 5:4 txdma_en 2'b0 transmit dma channel enable. must be set to enable a channel. bit 4 corresponds to channel 0, bit 5 to channel 1. 7:6 reserved 2'b0 reserved 8 p_reset 1'b0 port reset. writing a 1 to this bit will reset the entire mac and packet fifo interface as though it had come out of a system reset. all registers are restored to their default values thus disabling and resetting the dma engines, ethernet mode logic and packet fifo logic. the default for this bit is zero, so it will self-clear as part of the reset sequence. 9 reserved 1'b0 reserved 10 mac_rx_en 1'b0 if this bit is clear the receive ethernet media access engine will be held in reset. if this bit is set it will run normally. 11 mac_tx_en 1'b0 if this bit is clear the transmit ethernet media access engine will be held in reset. if this bit is set it will run normally. 12 byp_rx_en 1'b0 if this bit is clear the receive packet fifo engine will be held in reset. if this bit is set it will run normally. 13 byp_tx_en 1'b0 if this bit is clear the transmit packet fifo engine will be held in reset. if this bit is set it will run normally. 63:14 reserved 50'b0 reserved table 178: mac transmit dma control register mac_txd_ctl_0 - 00_1006_4420 mac_txd_ctl_1 - 00_1006_5420 mac_txd_ctl_2 - 00_1006_6420 this register is used in both ethernet and packet fifo modes bits name default description 3:0 weight_ch0 4'b0 transmit channel 0 round robin weight. note that if both channels are enabled with weight zero (the default) then no packets will be transmitted. 7:4 weight_ch1 4'b0 transmit channel 1 round robin weight. see note above. 63:8 reserved 56'b0 reserved bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 306 section 9: ethernet macs document 1250_1125-um100-r table 179: mac fifo threshold registers mac_thrsh_cfg_0 - 00_1006_4108 mac_thrsh_cfg_1 - 00_1006_5108 mac_thrsh_cfg_2 - 00_1006_6108 this register is used in both ethernet and packet fifo modes bits name default description 6:0 tx_wr_thrsh 7'b0 transmit fifo write threshold. sets the number of free 64 bit entries the transmit fifo must have before it signals that space is available. for dma operation this field must be set to 4 or 8 entries depending on the state of the tbx_en bit in the dma_config0 register. see section: ?transmitter configuration? on page 271 . 7 reserved 1'b0 reserved 14:8 tx_rd_thrsh 7'b0 transmit fifo read threshold. sets the number of valid 64 bit entries the transmit fifo must hold before the mac will start transmitting the packet. see section: ?transmitter configuration? on page 271 . note that the tx_wr_thrsh + tx_rd_thrsh must be less than the size of the fifo or the transmitter behaviour is unpredictable (tx_wr_thrsh + tx_rd_thrsh <= 32 for parts with system revision of 1, tx_wr_thrsh + tx_rd_thrsh <=128 for parts with revision greater than 2). 15 reserved 1'b0 reserved 21:16 tx_rl_thrsh 6'b0 transmit fifo release count. this sets the number of 64 bit fifo entries that will be held in the fifo when the mac is configured to hold the start of packets. see the tx_hold_sop_en bit in the mac_cfg register. see section: ?transmitter configuration? on page 271 . 23:22 reserved 2'b0 reserved 29:24 reserved 6'b0 reserved 31:30 reserved 2'b0 reserved 37:32 rx_rd_thrsh 6'b0 receive read threshold. this field sets the number of entries that must be in the receive fifo for it to indicate data is available to be read. for dma operation this field must be set to 4 entries. see section: ?receiver configuration? on page 274 39:38 reserved 2'b0 reserved 45:40 rx_rl_thrsh 6'b0 receive release threshold. this field sets the number of fifo entries that must be written at the start of a packet before any of the data is made available for reading. the data is also made available if the packet ends before the threshold is reached. see section: ?receiver configuration? on page 274 . this field must be greater than 2. if it is zero the mac receive behavior will be unpredictable. 55:46 reserved 10'b0 reserved 61:56 enc_fc_thrsh 6?h4 in encoded packt fifo modes link level flow control will be requested when the number of free doublewords in the receive fifo falls below this threshold. 63:62 reserved 2'b0 reserved user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 307 table 180: mac frame configuration registers mac_frame_cfg_0 - 00_1006_4118 mac_frame_cfg_1 - 00_1006_5118 mac_frame_cfg_2 - 00_1006_6118 this register is only used in both ethernet mode no fields apply for packet fifo modes bits name default description 5:0 ifg_rx rev >= periph_rev3 pre_len 6'b0 system revison < periph_rev3: the ifg_rx is not used in the current implementation. the ifg_tx value is used to set both receive to transmit (on half-duplex links) and transmit to transmit gap. system revision periph_rev3 and later: if bit [5] is clear a standard 7 byte preamble is transmitted. if bit [5] is set bits [3:0] set the number of bytes of preamble that will be transmitted ([3:0]=0 will result in one byte of preamble in gigabit mode, no preamble in 10/100 mode). the single sfd byte is always sent after the preamble. 11:6 ifg_tx 6'b0 ifg_tx determines inter-frame gap in interface cycles that the mac uses when doing back to back transmissions (or between a reception and transmission in a half- duplex link). when the mac has completed a packet the ifg counter loaded with the ifg_tx value and counts down. when the ifg counter reaches zero and four more cycles have passed the inter-frame gap time has elapsed and the mac is free to transmit. if the value written in this register is less than 4 then the gap will be 7 cycles, otherwise the gap will be ifg_tx+4 cycles (see figure 39). a value of zero gives 68 cycles. for gigabit operation this is in bytes, and for 10/100 in nibbles. including the offset of 4 for a standard 12 byte gap this field should be set to 8 for gigabit operation and 20 for 10/100. this value may only be changed while the protocol engine is held in reset, if it is changed while the engine is active the results are unpredictable. 17:12 ifg_thrsh 6'b0 this sets the threshold time in interface cycles for checking carrier sense during the inter-frame gap. at the start of the ifg the mac will monitor the carrier sense and defer if a carrier is detected, the ieee standard suggests this should last 2/3 of the gap. during the remainder of the ifg the mac ignores the carrier sense and transmission (potentially with a collision) will begin as usual. the carrier is ignored for the final ifg_thrsh+4 cycles of the ifg. to use the standard 2/3rd:1/3rd split for gigabit operation the mac should defer during the first 8 byte times, thus ifg_thrsh+4=4 and this field should be set to zero. for 10/100 operation the 8 byte times become 16 nibbles to defer, thus ifg_thrsh+4=8 and this field should be set to 4. this value may only be changed while the protocol engine is held in reset, if it is changed while the engine is active the results are unpredictable. 21:18 backoff_sel 4'b0 this field sets the maximum number of slot times the mac will backoff following a collision. if a collision happens when the mac is transmitting a packet it will abandon the transmission attempt, and backoff for a pseudo-random period before retrying. the length of the backoff is chosen randomly by a lfsr from a range from zero to a maximum value. the maximum backoff period depends on the number of times the packet has previously collided (to give an exponential backoff) and the value of this field. this field sets the maximum value the backoff count can grow to, regardless of the number of times the packet has collided. the encoding of the backoff time is: backoff_sel = 0 - backoff disabled, the backoff time will always be zero 1 <= backoff_sel <= 10 - backoff limit is 0 - (2^n - 1) 11 <= backoff_sel <= 15 - backoff limit is 0 - (2^10 - 1) this value may only be changed while the protocol engine is held in reset, if it is changed while the engine is active the results are unpredictable. this field should be set to 10 for standard operation. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 308 section 9: ethernet macs document 1250_1125-um100-r 29:22 lfsr_seed 8'b0 this field is the partial seed value for the lfsr that generates the random backoff. when the register is written this value is loaded into the 8 lowest bits of the lfsr (the upper 2 bits are loaded with the lfsr output). this value may be changed at any time. 39:30 slot_offset 10'b0 this field adjusts the slot size for the mac to match for delays in the phy. it is a signed value added to the base slot size. for 10/100 operation the slot size is (128 + slot_offset) nibble-clocks, giving the standard 512 bit times when the slot_offset is zero. for 1000 operation the slot size is (512 + slot_offset) byte-clocks, giving the standard 512 byte times when slot_offset is zero. this value may only be changed while the protocol engine is held in reset, if it is changed while the engine is active the results are unpredictable. 47:40 min_framesz 8'b0 this field sets the minimum frame size in bytes that is used. the mac will report a runt packet error for any packet that is received that is smaller than this number of bytes (after preamble and sfd have been stripped). for ieee 802.3 compliance this value should be 64 for all speeds of operation. this value may only be changed while the protocol engine is held in reset, if it is changed while the engine is active the results are unpredictable. this size must be greater than 9. 63:48 max_framesz 16'b0 this field sets the maximum frame size in bytes that is used. if a packet is received that is longer than this (after preamble and sfd have been stripped) the mac will report an oversize packet error and discard excess bytes. for ieee 802.3 compliance this value should be 1518 for all speeds of operation. setting this size above 1518 allows use of "jumbo" packets. this value may only be changed while the protocol engine is held in reset, if it is changed while the engine is active the results are unpredictable. this size must be greater than the min_framesz. table 180: mac frame configuration registers (cont.) mac_frame_cfg_0 - 00_1006_4118 mac_frame_cfg_1 - 00_1006_5118 mac_frame_cfg_2 - 00_1006_6118 this register is only used in both ethernet mode no fields apply for packet fifo modes bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 309 table 181: mac vlan tag registers mac_vlantag_0 - 00_1006_4110 mac_vlantag_1 - 00_1006_5110 mac_vlantag_2 - 00_1006_6110 this register is used in both ethernet and packet fifo modes bits name default description 31:0 tag 32'b0 vlan tag. this 32 bit tag is inserted into the packet after the destination and source ethernet addresses if the packet is marked for vlan tag insertion. the tag thus becomes bytes 12-15 of the packet. the low byte in this register is the first one put on the wire. note that for normal vlan operation the low two bytes should be 16?h8100. used only in ethernet mode. 39:32 tx_pkt_offset 8?b0 system revision periph_rev3 and later only. sets the offset the ethernet frame in transmitted packets. bits 34:32 must be 3'b000. used in both ethernet and packet fifo modes. 47:40 tx_crc_offset 8?b0 system revision periph_rev3 and later only. sets the offset for crc generation to begin in transmitted packets. bits 42:40 must be 3'b000. used in both ethernet and packet fifo modes. 48 ch_base_fc_en 1?b0 system revision periph_rev3 and later only. if this bit is clear pause frame flow control is done in the mac, if set the flow control is done by the dma engine. used in both ethernet and packet fifo modes. 63:49 notimp 32?b0 not implemented. table 182: mac status registers mac_status_0 - 00_1006_4408 mac_status_1 - 00_1006_5408 mac_status_2 - 00_1006_6408 read only - reading this register will clear all latched bits this register is used in both ethernet and packet fifo modes bits name default description 0 rx_ch0_eop_count 1?b0 set if the eop interrupt was raised as a result of the packet count being reached. 1 rx_ch0_eop_timer 1?b0 set if the eop interrupt was raised as a result of the packet timer triggered. 2 rx_ch0_eop_seen 1?b0 set at the end of any packet transfer. it can be used during polling to determine if any packets have been transferred since the register was read (regardless of the setting of the int_pktcnt field). 3 rx_ch0_hwm 1?b0 this bit will be set if the current descriptor count is less than the high watermark. this bit is not latched nor cleared by a read of the status register. it always reflects the state at the time the register is read. therefore it is possible that the bit may become set and cause an interrupt but be cleared by an in-flight write that adds descriptors before the interrupt is taken. 4 rx_ch0_lwm 1?b0 this bit will be set if the current descriptor count is less than the low watermark. this bit is not latched (see bit 3). 5 rx_ch0_dscr 1?b0 set if the interrupt is triggered by a descriptor with the interrupt bit set. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 310 section 9: ethernet macs document 1250_1125-um100-r 6 rx_ch0_derr 1?b0 set if any error is marked on data returned by a read. the channel will be stopped. software must disable and re-enable the channel to clear this fault. 7 rx_ch0_drop 1?b0 set if a packet was dropped because there were no descriptors available when the start of packet was received. (if there are descriptors available for the start of packet, but the controller runs out of descriptors during the packet reception then the dscr_err bit will be set in the receive status word for the packet.) the interface will continue dropping data until there are descriptors available when a start of packet is received. 8 rx_ch1_eop_count 1?b0 set if the eop interrupt was raised as a result of the packet count being reached. 9 rx_ch1_eop_timer 1?b0 set if the eop interrupt was raised as a result of the packet timer triggered. 10 rx_ch1_eop_seen 1?b0 set at the end of any packet transfer. it can be used during polling to determine if any packets have been transferred since the register was read (regardless of the setting of the int_pktcnt field). 11 rx_ch1_hwm 1?b0 this bit will be set if the current descriptor count is less than the high watermark. this bit is not latched (see bit 3). 12 rx_ch1_lwm 1?b0 this bit will be set if the current descriptor count is less than the low watermark. this bit is not latched (see bit 3). 13 rx_ch1_dscr 1?b0 set if the interrupt is triggered by a descriptor with the interrupt bit set. 14 rx_ch1_derr 1?b0 set if any error is marked on data returned by a read. the channel will be stopped. software must disable and re-enable the channel to clear this fault. 15 rx_ch1_drop 1?b0 set if a packet was dropped because there were no descriptors available when the start of packet was received. (if there are descriptors available for the start of packet, but the controller runs out of descriptors during the packet reception then the dscr_err bit will be set in the receive status word for the packet.) the interface will continue dropping data until there are descriptors available when a start of packet is received. 16 tx_ch0_eop_count 1?b0 set if the eop interrupt was raised as a result of the packet count being reached. 17 tx_ch0_eop_timer 1?b0 set if the eop interrupt was raised as a result of the packet timer triggered. 18 tx_ch0_eop_seen 1?b0 set at the end of any packet transfer. it can be used during polling to determine if any packets have been transferred since the register was read (regardless of the setting of the int_pktcnt field). 19 tx_ch0_hwm 1?b0 this bit will be set if the current descriptor count is less than the high watermark. this bit is not latched (see bit 3). 20 tx_ch0_lwm 1?b0 this bit will be set if the current descriptor count is less than the low watermark. this bit is not latched (see bit 3). 21 tx_ch0_dscr 1?b0 set if the interrupt is triggered by a descriptor with the interrupt bit set. 22 tx_ch0_derr 1?b0 set if data marked with an error is returned for any read (descriptor or data buffer). the channel will be stopped. software must disable and re-enable the channel to clear this fault. 23 tx_ch0_dzero 1?b0 set if a descriptor has a packet length of zero or the sop flag bit is not set in the first descriptor of a packet. this bit is also set if the controller runs out of descriptors during a packet transmission. the channel will be stopped. software must disable and re-enable the channel to clear this fault. 24 tx_ch1_eop_count 1?b0 set if the eop interrupt was raised as a result of the packet count being reached. 25 tx_ch1_eop_timer 1?b0 set if the eop interrupt was raised as a result of the packet timer triggered. table 182: mac status registers (cont.) mac_status_0 - 00_1006_4408 mac_status_1 - 00_1006_5408 mac_status_2 - 00_1006_6408 read only - reading this register will clear all latched bits this register is used in both ethernet and packet fifo modes bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 311 26 tx_ch1_eop_seen 1?b0 set at the end of any packet transfer. it can be used during polling to determine if any packets have been transferred since the register was read (regardless of the setting of the int_pktcnt field). 27 tx_ch1_hwm 1?b0 this bit will be set if the current descriptor count is less than the high watermark. this bit is not latched (see bit 3). 28 tx_ch1_lwm 1?b0 this bit will be set if the current descriptor count is less than the low watermark. this bit is not latched (see bit 3). 29 tx_ch1_dscr 1?b0 set if the interrupt is triggered by a descriptor with the interrupt bit set. 30 tx_ch1_derr 1?b0 set if data marked with an error is returned for any read (descriptor or data buffer). the channel will be stopped. software must disable and re-enable the channel to clear this fault. 31 tx_ch1_dzero 1?b0 set if a descriptor has a packet length of zero or the sop flag bit is not set in the first descriptor of a packet. this bit is also set if the controller runs out of descriptors during a packet transmission. the channel will be stopped. software must disable and re-enable the channel to clear this fault. 39:32 reserved 8?b0 reserved 40 rx_undrfl 1'b0 this bit is set by the receive fifo underflowing. if this happens when dma is being used then the rx_rd_thrsh is incorrectly set. 41 rx_ovrfl 1'b0 this bit is set by the receive fifo overflowing. this happens if the dma (or reader in direct mode) has delayed reading data from the fifo so there is no space for the next received data. 42 tx_undrfl 1'b0 this bit is set if the transmit fifo underflows. this happens if the dma (or sender in direct mode) has delayed inserting data into the fifo and it was empty when more data was needed to be transmitted. 43 tx_ovrfl 1'b0 this bit is set by the transmit fifo overflowing. this happens if the dma (or sender in direct mode) writes to the fifo when it is full. this will only happen for dma if the tx_wr_thrsh threshold is incorrectly set. 44 ltcol_err 1'b0 this bit will be set when a packet experiences a late collision. a late collision is one that happens after the minimum packet size has been sent. collisions can never happen in packet fifo modes. 45 excol_err 1'b0 this bit is set if a packet experiences excessive collisions. it is signalled when attempted transmission of the packet collides 16 times. it normally indicates a hardware problem, but can also be caused by a very busy network or in the unlucky case of the random backoff lfsr being synchronized with another host (normally this will be fixed by the different length of time the two devices take to respond and clear the excessive collision error, but it is also possible to set a different lfsr_seed in the mac_cfg register). collisions can never happen in packet fifo modes. 46 cntr_ovrfl_err 1'b0 this bit is set if any of the rmon counters overflow. whenever a counter overflows this bit is set and the counter number is written into the counter_addr field. the rmon counters are not used in packet fifo modes. 51:47 counter_addr 5'b0 this is the number of the most recent rmon counter that overflowed. it is only valid if the cntr_ovrfl_err bit is set. the rmon counters are not used in packet fifo modes. table 182: mac status registers (cont.) mac_status_0 - 00_1006_4408 mac_status_1 - 00_1006_5408 mac_status_2 - 00_1006_6408 read only - reading this register will clear all latched bits this register is used in both ethernet and packet fifo modes bits name default description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 312 section 9: ethernet macs document 1250_1125-um100-r 52 tx_pause_on 1'b0 system revision periph_rev3 or greater. this bit is set when the mac has received a pause frame and the pause time indicated has not expired. it is cleared when the pause time expires (or if a pause freme with zero time is received). no interrupt can be generated from this bit. pause frames are not used in packet fifo modes. 63:53 reserved 11'b0 reserved table 182: mac status registers (cont.) mac_status_0 - 00_1006_4408 mac_status_1 - 00_1006_5408 mac_status_2 - 00_1006_6408 read only - reading this register will clear all latched bits this register is used in both ethernet and packet fifo modes bits name default description table 183: mac status 1 register mac_status1_0 - 00_1006_4430 mac_status1_1 - 00_1006_5430 mac_status1_2 - 00_1006_6430 read only reading this register will clear the channel 1 latched bits this register is used in both ethernet and packet fifo modes bits name default description 63:0 status 64'h0 reading this register gives the same result as reading the status register, except that only the latched bits associated with channel 1 transmit and receive dma are cleared. it is for use in split interrupt mode. table 184: mac debug status registers mac_debug_status_0 - 00_1006_4448 mac_debug_status_1 - 00_1006_5448 mac_debug_status_2 - 00_1006_6448 read only this register is used in both ethernet and packet fifo modes bits name default description 63:0 status 64'b0 reading this register gives the same result as reading the status register, except the bits are not cleared and none of the other side effects happen. it is intended for debug accesses to the status. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 313 table 185: mac interrupt mask registers mac_int_mask_0 - 00_1006_4410 mac_int_mask_1 - 00_1006_5410 mac_int_mask_2 - 00_1006_6410 this register is used in both ethernet and packet fifo modes bits name default description 46:0 mask 47'b0 setting a bit in this register enables generation of an interrupt when the corresponding bit is set in the mac_status register. 47 split_en 1'b0 when this bit is set the channel 1 interrupts will be signalled on the channel 1 interrupt instead of standard interrupt, and reads to the mac_status register will not clear channel 1 state. when this bit is clear all interrupts are signalled on the standard interrupt and reading the mac_status register clears all state. 63:48 reserved 19'b0 reserved table 186: mac fifo pointer registers mac_rx_fifo_ptrs_0 - 00_1006_4120 mac_rx_fifo_ptrs_1 - 00_1006_5120 mac_rx_fifo_ptrs_2 - 00_1006_6120 mac_tx_fifo_ptrs_0 - 00_1006_4128 mac_tx_fifo_ptrs_1 - 00_1006_5128 mac_tx_fifo_ptrs_2 - 00_1006_6128 read only - broadcom use only this register is used in both ethernet and packet fifo modes bits name default description 63:0 status 64'hx status for fifo and counts (broadcom use only) table 187: mac receive address filter exact match registers mac_addr0_0 - 00_1006_4280 mac_addr0_1 - 00_1006_5280 mac_addr0_2 - 00_1006_6280 mac_addr1_0 - 00_1006_4288 mac_addr1_1 - 00_1006_5288 mac_addr1_2 - 00_1006_6288 mac_addr2_0 - 00_1006_4290 mac_addr2_1 - 00_1006_5290 mac_addr2_2 - 00_1006_6290 mac_addr3_0 - 00_1006_4298 mac_addr3_1 - 00_1006_5298 mac_addr3_2 - 00_1006_6298 mac_addr4_0 - 00_1006_42a0 mac_addr4_1 - 00_1006_52a0 mac_addr4_2 - 00_1006_62a0 mac_addr5_0 - 00_1006_42a8 mac_addr5_1 - 00_1006_52a8 mac_addr5_2 - 00_1006_62a8 mac_addr6_0 - 00_1006_42b0 mac_addr6_1 - 00_1006_52b0 mac_addr6_2 - 00_1006_62b0 mac_addr7_0 - 00_1006_42b8 mac_addr7_1 - 00_1006_52b8 mac_addr7_2 - 00_1006_62b8 this register is used in both ethernet and packet fifo modes bits name default description 47:0 address 48'bx the destination address to be exactly matched as part of input packet filtering. the incoming address is always compared to all entries. the low byte in this register corresponds with the first byte of the address to be received. 63:48 zero 16'b0 reads as zero, writes ignored. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 314 section 9: ethernet macs document 1250_1125-um100-r table 188: mac receive address filter mask registers (only if system revision >= periph_rev3) mac_admask0_0 - 00_1006_4218 mac_admask0_1 - 00_1006_5218 mac_admask0_2 - 00_1006_6218 mac_admask1_0 - 00_1006_4220 mac_admask1_1 - 00_1006_5220 mac_admask1_2 - 00_1006_6220 this register is used in both ethernet and packet fifo modes bits name default description 47:0 mask 48'b ffff_ ffff_ ffff the mask qualifies the destination address set in the corresponding mac_addr register. when the incoming address is compared to the address any bits with a mask of zero are excluded from the comparison. the low byte in this register corresponds with the first byte of the address to be received. 63:48 zero 16'b0 reads as zero, writes ignored. table 189: mac receive address filter hash match registers mac_hash0_0 - 00_1006_4240 mac_hash0_1 - 00_1006_5240 mac_hash0_2 - 00_1006_6240 mac_hash1_0 - 00_1006_4248 mac_hash1_1 - 00_1006_5248 mac_hash1_2 - 00_1006_6248 mac_hash2_0 - 00_1006_4250 mac_hash2_1 - 00_1006_5250 mac_hash2_2 - 00_1006_6250 mac_hash3_0 - 00_1006_4258 mac_hash3_1 - 00_1006_5258 mac_hash3_2 - 00_1006_6258 mac_hash4_0 - 00_1006_4260 mac_hash4_1 - 00_1006_5260 mac_hash4_2 - 00_1006_6260 mac_hash5_0 - 00_1006_4268 mac_hash5_1 - 00_1006_5268 mac_hash5_2 - 00_1006_6268 mac_hash6_0 - 00_1006_4270 mac_hash6_1 - 00_1006_5270 mac_hash6_2 - 00_1006_6270 mac_hash7_0 - 00_1006_4278 mac_hash7_1 - 00_1006_5278 mac_hash7_2 - 00_1006_6278 this register is used in both ethernet and packet fifo modes bits name default description 63:0 map 64'bx the hash map bits for a hash based match as part of input packet filtering. set the bit to zero to not match that hash value, and to one to match on the hash value. table 190: mac transmit source address registers mac_ethernet_addr_0 - 00_1006_4208 mac_ethernet_addr_1 - 00_1006_5208 mac_ethernet_addr_2 - 00_1006_6208 this register is only used ethernet mode bits name default description 47:0 address 48'b0 the source address to be put in outgoing packets. the low byte of this register will be the first byte of the address transmitted. pause frames will be accepted on the address configured in this register (in addition to the well known multicast address). the address in this register will be used as the source address when the mac sends a pause frame. 63:48 zero 16'b0 reads as zero, writes ignored. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 315 table 191: mac packet type configuration registers mac_type_cfg_0 - 00_1006_4210 mac_type_cfg_1 - 00_1006_5210 mac_type_cfg_2 - 00_1006_6210 this register is used in both ethernet and packet fifo modes bits name default description 15:0 type0 16'b0 if a received packet has this packet type the receive descriptor will be written with type = 3?b100. the high byte is compared with the first byte received in the type field, the low byte with the second type byte. 31:16 type1 16'b0 if a received packet has this packet type the receive descriptor will be written with type = 3?b101. the high byte is compared with the first byte received in the type field, the low byte with the second type byte. 47:32 type2 16'b0 if a received packet has this packet type the receive descriptor will be written with type = 3?b110. the high byte is compared with the first byte received in the type field, the low byte with the second type byte. 63:48 type3 16'b0 if a received packet has this packet type the receive descriptor will be written with type = 3?b111. the high byte is compared with the first byte received in the type field, the low byte with the second type byte. table 192: mac receive address filter control registers mac_adfilter_cfg_0 - 00_1006_4200 mac_adfilter_cfg_1 - 00_1006_5200 mac_adfilter_cfg_2 - 00_1006_6200 this register is used in both ethernet and packet fifo modes bits name default description 0 allpkt_en 1'b0 when this bit is set all packets will be accepted (promiscuous mode). used in both ethernet and packet fifo modes. 1 ucast_en 1'b0 when this bit is set unicast packets are checked in the hash map. used in both ethernet and packet fifo modes. 2 ucast_inv 1'b0 when this bit is set unicast packets that miss in the hash map will be accepted. if it is clear unicast packets must hit to be accepted. used in both ethernet and packet fifo modes. 3 mcast_en 1'b0 when this bit is set multicast packets are checked in the hash map. used in both ethernet and packet fifo modes. 4 mcast_inv 1'b0 when this bit is set multicast packets that miss in the hash map will be accepted. if it is clear multicast packets must hit to be accepted. used in both ethernet and packet fifo modes. 5 bcast_en 1'b0 when this bit is set all broadcast packets are accepted. when it is clear all broadcast packets are dropped. used in both ethernet and packet fifo modes. 6 direct_inv 1'b0 when this bit is set packets will be accepted if they do not match any of the entries in the exact address match registers. when this bit is clear packets will be accepted if they match any entry in the direct address match registers. used in both ethernet and packet fifo modes. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 316 section 9: ethernet macs document 1250_1125-um100-r 7 allm_en 1?b0 when this bit is set all multicast packets are accepted. when it is clear multicast packets will only be accepted if they match in the exact or hash filters. used in both ethernet and packet fifo modes. 15:8 iphdr_offset 8'b0 byte in the packet (counting from 1) of the ip header for checking the ipv4 header checksum. this is normally 15, but may be different if encapsulation headers are prepended. this offset is also used by the tcp checksum checking. used only in ethernet mode. 23:16 rx_crc_offset 8'b0 system revision periph_rev3 and later only. sets the offset for crc checking to begin in received packets. bits 18:16 must be 3'b000. used in both ethernet and packet fifo modes. 31:24 rx_pkt_offset 8'b0 system revision periph_rev3 and later only. sets the offset for the ethernet frame in received packets. bits 26:24 must be 3'b000. used in both ethernet and packet fifo modes. 32 fwdpause_en 1'b0 system revision periph_rev3 and later only. if this bit is set then pause frames will not be processed by the hardware and will be accepted and passed to the dma engine as though they had passed the address filter. this allows software to do pause frame flow control (for example to only disable the best-effort tx dma channel when a pause is requested, but allow the priority traffic to continue). used only in ethernet mode. 33 vlan_det_en 1'b0 system revision periph_rev3 and later only. if this bit is set then 4 is added to the ip_hdr_offset if the type field in the mac header (i.e. at mac_hdr_off +12 and +13) is the vlan type 81-00. this allows the correct ip header offset to be used for a network with a mix of vlan and non-vlan packets. in addition when the 81-00 type is detected the vlan_pkt bit (written to bit 1 of the dscr_b "options" field i.e. just above the bad_tcpcs bit) will be set and the pkt_type field in the status will come from decoding the two bytes following the vlan tag (i.e. the packet type from the untagged packet). used only in ethernet mode. 41:34 rx_ch_msn_sel 8'b0 system revision periph_rev3 and later only. this field specifies the offset of the upper four bits of the channel selection index when the split_ch_sel bit is set in the mac_cfg register. note that if rx_ch_msn_sel <= {rx_ch_sel_msb,rx_ch_sel} the channel selected is unpredictable. used in both ethernet and packet fifo modes. 63:42 reserved 22'b0 reserved table 192: mac receive address filter control registers (cont.) mac_adfilter_cfg_0 - 00_1006_4200 mac_adfilter_cfg_1 - 00_1006_5200 mac_adfilter_cfg_2 - 00_1006_6200 this register is used in both ethernet and packet fifo modes bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 317 table 193: mac receive channel select map registers mac_chlo0_0 - 00_1006_4300 mac_chlo0_1 - 00_1006_5300 mac_chlo0_2 - 00_1006_6300 mac_chlo1_0 - 00_1006_4308 mac_chlo1_1 - 00_1006_5308 mac_chlo1_2 - 00_1006_6308 mac_chlo2_0 - 00_1006_4310 mac_chlo2_1 - 00_1006_5310 mac_chlo2_2 - 00_1006_6310 mac_chlo3_0 - 00_1006_4318 mac_chlo3_1 - 00_1006_5318 mac_chlo3_2 - 00_1006_6318 mac_chup0_0 - 00_1006_4320 mac_chup0_1 - 00_1006_5320 mac_chup0_2 - 00_1006_6320 mac_chup1_0 - 00_1006_4328 mac_chup1_1 - 00_1006_5328 mac_chup1_2 - 00_1006_6328 mac_chup2_0 - 00_1006_4330 mac_chup2_1 - 00_1006_5330 mac_chup2_2 - 00_1006_6330 mac_chup3_0 - 00_1006_4338 mac_chup3_1 - 00_1006_5338 mac_chup3_2 - 00_1006_6338 this register is used in both ethernet and packet fifo modes bits name default description 63:0 map 64'b0 these registers form the table for mapping the 8 bits from a received packet into a two bit channel number. the 256 entry table has bit 0 register 0 as entry 0, and bit 63 register 3 as entry 255. the chup register provides the msb and the chlo register the lsb of the channel number. table 194: mac mii management interface registers mac_mdio_0 - 00_1006_4428 mac_mdio_1 - 00_1006_5428 mac_mdio_2 - 00_1006_6428 this register is used in both ethernet and packet fifo modes bits name default description 0 mdc 1'b0 mii management interface clock, this bit is copied to the mdc pin. 1 mdio_dir 1'b0 mii management data direction, when set the mdio pin is an input, when clear the mdio pin is driven from the mdio_out bit. this bit must be clear to allow receive flow control to be output when the interface is configured for encoded packet fifo mode operation. 2 mdio_out 1'b0 mii management interface data out, this bit is copied to the mdio pin if the mdio_dir bit is 0. 3 genc 1'b0 general output, this bit is copied to the geno pin. 4 mdio_in 1'b0 mii management interface data input, this read only bit gives the value on the mdio pin. 63:5 reserved 59'b0 reserved bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 318 section 9: ethernet macs document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 9: ethernet macs page 319 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 320 section 10: serial interfaces document 1250_1125-um100-r section 10: serial interfaces i ntroduction the part incorporates two identical serial ports that provide full-duplex interfaces to a variety of serial devices. each port is separately configured, and can be run as an asynchronous serial link from 1200 baud to 5 mbaud or a synchronous serial link at up to 55 mbps. in asynchronous mode the programming model is based on a duart. some registers share information between the a and b channels, but the two ports can be independently switched to the synchronous mode. in synchronous mode the serial interface includes an internal hdlc engine and externally provides a pcm highway style link. selection between asynchronous and synchronous interf aces is normally made at reset time using the configuration input on io_ad[12] (channel a) and io_ad[14] (channel b). however, the cpu can write the corresponding bits in the system_cfg register to change the selection. modifying this bit will switch the output pins between the asynchronous drivers and the synchronous ones. if the interface is switched between modes software will need to re-initialize the interface and may need to reset the external device. each serial port has 8 pins associated with it. in addition if an interface is in synchronous mode it can use one of the gpio pins as an output (software cannot change the use of this pin, it can only be set by the reset configuration). the following table shows their use in each mode, and for asynchronous mode the correspondence between the pins and input or output registers for channel a and channel b. table 195: serial interface signal names pin name direction a b asynchronous mode synchronous mode dout output transmit data output transmit data output din input receive data input receive data input rts_ tstrobe output op[0] op[1] rts output or general output transmit strobe output cout output op[2] op[3] general output (e.g. for dtr handshake) or baud rate clock output clock output cts_ tclkin input ip[0] ip[1] cts input, or general input with transision detector transmit clock input cin_ rclkin input ip[2] ip[3] general input with transition detector (e.g. for dsr handshake) receive clock input tin input ip[4] ip[5] general input (e.g. for dcd) transmit enable or synchronization input rin input ip[6] ip[7] general input (e.g. for ri) receive enable or synchronization input rstrobe (shared with gpio) output receive strobe output (if this is not enabled the pins are used for gpio[0] or gpio[1]) user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 321 a synchronous m ode the asynchronous interface is provided using a duart. the two channels are separately programmable and each has its own baud rate generator. each channel has a 16 byte transmit fifo and a 16 byte receive fifo. in addition to the data path there are 4 inputs and 2 outputs per channel that can either be used for flow control or are available for general use. the inputs are readable through the input port register (ipr), and the outputs are set through the output port register (opr). even numbered i/o lines are associated with channel a, and odd numbered lines with channel b. the uart supports rts/cts flow control in hardware, other control must be done in software. when serial port 0 is set in asynchronous mode it is driven from channel a of the duart, serial port 1 in asynchronous mode is driven from channel b. b aud r ate g enerators the baud rate is generated on chip by dividing down from the 100mhz reference clock. each channel can have a different baud rate, but for a channel the transmit and receive rates must be the same. the baud rate is selected by setting the duart_clk_sel register to (100 mhz/(baud_rate * 20)) - 1 some popular baud rates are shown in the table below. the baud clock can be output on the cout pin by setting the appropriate bit in the output port configuration register duart_opcr . the baud clock is also used for the synchronous serial interface when it is configured to use an internal clock. in this case cout should be configured to pass the clock signal to the external devices. table 196: baud rate counter values baud rate count actual % error 1200 4095 1220.703 1.72526 2400 2082 2400.384 0.016003 4800 1040 4803.074 0.064041 9600 519 9615.385 0.160256 19200 259 19230.77 0.160256 38400 129 38461.54 0.160256 57600 85 58139.53 0.936693 115200 42 116279.1 0.936693 230400 21 227272.7 -1.35732 500000 9 500000 0 1000000 4 1000000 0 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 322 section 10: serial interfaces document 1250_1125-um100-r o peration the two channels of the duart are identical in terms of configuration and operation. they are controlled by a set of memory mapped registers, in most cases separate registers are provided for channel a and channel b (the register names are identical with either _a or _b indicating the channel); in a few cases the two channels are combined. prior to operation a channel must be configured. the duart_mode_reg_1 is used to set the number of data bits in a character (either 7 or 8) and whether parity should be added. the parity bit may be set to give either an even or odd number of ones, or to be fixed as a high (mark) or low (space). the number of stop bits are set in the duart_mode_reg_2 . these registers are also used to enable hardware rts/cts handshake separately in each direction. the baud rate should be set in the duart_clk_sel register. the mode and clock registers should only be written while the interface is inactive, changing the parameters while the uart is active results in unpredictable behavior. once configured the transmitter and receiver are enabled by writing the duart_cmd register. the transmitter indicates that it is able to accept data into the transmit fifo by setting the duart_tx_rdy bit in the duart_status register. for as long as this bit is set, the cpu can write characters to the duart_tx_hold register and they will be inserted in the transmit fifo. if the transmitter is enabled characters are extracted from the fifo, have a (low) start bit prepended, parity and (high) stop bits appended and are serialized (least significant bit first) and sent to the dout pin. the transmitter may be disabled or reset by issuing a command to the duart_cmd register. disabling transmission will cause transmission to stop and the line idle (high) when transmission of the current character is complete, any characters in the fifo will remain there to be sent when the transmitter is re-enabled. the break command is similar to disable except when transmission of the current character (including stop bits) is complete the line is driven low. the break condition is cleared with the stop-break command, which removes the break synchronously with the transmit bit clock. resetting the transmitter will cause the current transmission to be aborted and all characters in the fifo to be discarded, all transmitter state is cleared and it is left in the disabled state. until the fifo becomes full characters can continue to be inserted into the fifo even if the transmitter is disabled (if the disabled state was reached through the reset command any characters in the fifo when the reset was issued are lost, after this characters can be inserted into the now empty fifo). the receiver will detect the (low) start bit on the din line, and use it to synchronize the local bit clock. data bits are then sampled in the middle of the bit time until the data and parity bits have been received. one additional bit is sampled, and an error reported if it is not the expected (high) stop bit. once a character has been received it is put in to the fifo along with the frame and parity error flags. if the fifo becomes full the character is discarded and the first character to be received that can be put in to the fifo will have the overrun status flag set (thus the overrun flag indicates that characters were lost before the one that is marked). there are two error conditions may result if the stop bit was not detected. if the data received is all zeros and a zero is seen in place of the stop bit then the break condition is detected. a zero character is put in the fifo along with the break-detected flag, the receiver will not resume operation until the break condition has been removed by the line being high for two bit times. if the data received is not all zeros but a zero is seen in place of the stop bit then a frame error is reported, the input data continues to be sampled for half a bit time. during this period, if the input is sampled high it is considered as a late stop bit and the line is monitored for the next start bit. if the input remains low for the full half bit time then it is considered to be an early start bit and the receiver will synchronize at the half bit time point and start assembly of the next character. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 323 when there is a character in the receive fifo the duart_rx_rdy bit in the duart_status register is set, and the cpu can read it from the duart_rx_hold register. reading the duart_rx_hold register removes the character from the fifo. the top four bits of the status register reflect the flags (overrun error, parity error, frame error and break) associated with the character (since reading the character pops it out of the fifo the flags should be read before the character). if the duart_rx_hold register is read at a time when the duart_rx_rdy bit is not set the result is unpredictable. the receiver may be disabled or reset by issuing a command to the duart_cmd register. both of these have immediate effect, any character in the process of being received is discarded. reset will also discard all data in the fifo, disabling the receiver will retain it and reading from the fifo can continue. in both cases the receiver must be enabled by writing the command register. handshaking using the rts/cts protocol is implemented in hardware. it is enabled separately for the transmitter (in duart_mode_reg_2 ) and the receiver (in duart_mode_reg_1 ). when enabled the transmitter will monitor the state of the cts_tclkin pin, and will only start sending a character if the signal is low. once transmission of a character has started it will continue until the character has been sent regardless of the state of cts_tclkin. when enabled the rts_tstrobe pin is driven by the receiver. it will be set low if the receiver is enabled and is able to receive a character. on receiving a start bit that will cause the receiver to become full the rts_tstrobe line will be deasserted (set high), to indicate that no further characters should be sent. if hardware handshaking is disabled the rts_tstrobe output is controlled from software, and will reflect the inverse of the op[0] bit for channel a or the op[1] bit for channel b. the op bits can be set by writing to the duart_set_opr register and cleared by writing to the duart_clear_opr register. for convenience of systems implementing software flow control the op[0] and op[1] bits (that control rts_tstrobe) can also be set and cleared through the duart_out_port register. the cts_tclkin pin can always be read through the duart_in_port register. the baud rate clock that the transmitter is using can be output on the cout pin, alternatively the pin can be driven from software as the inverse of op[2] or op[3]. this is set in the output port configuration register duart_opcr . the cin_rclkin, rin and tin pins are provided in the duart_in_port register for software to use either as separate handshake lines or as general inputs. the cts_tclkin and cin_rclkin lines have transition detectors associated with them and the upper four bits of the duart_inport_chng register will latch the fact the line changed since the last time the register was read (the read automatically clears the bits). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 324 section 10: serial interfaces document 1250_1125-um100-r i nterrupts the duart interrupts are provided as system interrupts 8 (for channel a) and 9 (for channel b). the conditions that can cause an interrupt are signalled in the interrupt status register duart_isr . this contains the channel a status in the lower four bits and the channel b status in the upper four bits. for convenience the information for each channel is available in the duart_isr_a and duart_isr_b registers where the status for the channel is always in the lower four bits and the upper bits are ze ros. the conditions that can cause an interrupt are: transmitter ready, receiver ready or receiver fifo full , break detected or removed and change detected on the handshake lines. corresponding to each bit in the interrupt status register there is a bit in the interrupt mask register duart_imr , if a status bit is set and the corresponding mask bit is also set then an interrupt will be raised. again, for programming convenience, aliases of the lower and upper bits of the mask are provided in the lower four bits of the duart_imr_a and duart_imr_b registers (these are aliases - internally there is only a single copy of each mask bit). figure 66 shows the interrupt generation for a single channel. figure 66: uart interrupt generation duart_mode[6] rx_irqsel 1 0 rx_fifo_not_empty rx_fifo_full s r [1] [3] [2] state change detect reset_break_command rx_break interrupt duart_imr[3:0] (ch a) duart_imr[7:4] (ch b) duart_aux[0] (ch a) duart_aux[1] (ch b) s r duart_aux[2] (ch a) duart_aux[3] (ch b) s r duart_ipcr[4] (ch a) duart_ipcr[5] (ch b) duart_ipcr[6] (ch a) duart_ipcr[7] (ch b) state change detect ctstclkin duart_ipcr[0] (ch a) duart_ipcr[1] (ch b) state change detect cinrclkin duart_ipcr[2] (ch a) duart_ipcr[3] (ch b) duart_ipcr_read duart_mode[5] tx_irqsel 1 0 tx_fifo_empty tx_ready [0] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 325 the transmit interrupt can be generated either by there being at least one free entry in the fifo (i.e. when the duart_tx_rdy status bit is set) or when the fifo is empty. the tx_irq_sel bit in the duart_mode_reg_1 is used to select between them. the isr status bit is cleared by the write of the duart_rx_hold register that removes the condition (causes the fifo to go full or not-empty depending on the mode). the receive interrupt can be generated either by there being at least one character in the fifo (i.e. when the duart_rx_rdy status bit is set) or when the fifo is full (or almost full). the rx_irq_sel bit in the duart_mode_reg_1 is used to select between them. the isr status bit is cleared by the read of the duart_rx_hold register that removes the condition (causes the fifo to go empty or not-full depending on the mode). if the ?fifo full? interrupt source is selected the duart_sig_full field in the duart_full_ctl register can be used to set the number of characters that must be in the receive fifo for the interrupt to be raised. the interrupt is asserted when the fifo contains more than this number of characters. by default this field is 15, causing the interrupt when the fifo is completely full. with this setting software must respond to the interrupt and read from the fifo within one character time to avoid the fifo overflowing and characters being lost. the level at which the interrupt is raised can be lowered to provide more character times of interrupt latency. if the duart_int_time field in the duart_full_ctl register is non-zero and the uart is set to interrupt on rx full (duart_rx_irq_sel bit =1) then an interrupt will be raised if the rx fifo is not empty and the link has been idle for duart_int_time*16 bit times. if duart_int_time is zero then there is no timeout. this timeout ensures that characters received when the fifo is below threshold will not suffer long latencies before being serviced. if either the threshold or timeout mechanism are used the receive interrupt status bit in the duart_isr register will be set based on the threshold or timeout. however the duart_rx_ffull bit in the duart_status register will continue to reflect the real full state of the fifo. the fifo will continue to accept characters until it is really full regardless of threshold and timeout settings. the change in break interrupt status is set by the detection of the start of a break and by the detection of the end of a break. it will remain set until the cpu issued a reset break change command to the duart_cmd register. the input line transition detector interrupt combines the state change information for both input lines of the channel. they are individually enabled in the duart_aux_ctrl registers. the interrupt status is cleared by reading the duart_inport_chng register. l oopback there are two loopback modes for diagnostics. they are enabled by setting the duart_chan_mode bits in the duart_mode_reg_2 . in local loopback mode the transmitter data output is internally connected to the receiver data input, so any character transmitted will be received. in this mode the dout pin is held idle (high) and the din pin is ignored. during local loopback the transmit module will not check the cts_tclkin pin and the receive module will not set the rts_tstrobe pin even if their enable bits (duart_tx_cts_ena in duart_mode_reg_2 and duart_rx_rts_ena in duart_mode_reg_1 ) are set. while the interface is in local loopback mode the receiver will be active even if it has not been enabled. the transmitter must still be enabled for characters to be sent. in remote loopback mode data received on the din pin is re-clocked and transmitted on the dout, the received character is not put in to the fifo and no error checking is done. in remote loopback mode received data is always sent out, the transmit module does not check the cts_tclkin pin even if duart_tx_cts_ena bit is set in the duart_mode_reg_2 . bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 326 section 10: serial interfaces document 1250_1125-um100-r duart r egisters table 197: duart mode registers duart_mode_reg_1_a - 00_1006_0100 duart_mode_reg_1_b - 00_1006_0200 bits name default description 1:0 duart_bits_per_char 2'b00 0: 8 1: reserved 2: 7 3: 8 2 duart_parity_type 1'b0 parity type: 0: even/low 1: odd/high 4:3 duart_parity_mode 2'b0 parity mode. 0: add parity (even/odd selected by bit 2) 1: add fixed parity bit (low/high selected by bit 2) 2: no parity 3: no parity 5 duart_tx_irq_sel 1'b0 transmitter interrupt select. 0: interrupt when the transmitter is ready (there is space in the fifo for at least one character). 1: interrupt when the transmit fifo is empty. 6 duart_rx_irq_sel 1'b0 receiver interrupt select. 0: interrupt on receiver ready (at least one character in the fifo). 1: interrupt on receiver fifo full 7 duart_rx_rts_ena 1'b0 receiver request-to-send control enable. channel a: if set the s0_rts_tstrobe pin will be used as hardware controlled rts, if clear the pin will output the inverse of op[0]. channel b: if set the s1_rts_tstrobe pin will be used as hardware controlled rts, if clear the pin will output the inverse of op[1]. 63:8 notimp 56?bx not implemented. table 198: duart second mode registers duart_mode_reg_2_a - 00_1006_0110 duart_mode_reg_2_b - 00_1006_0210 bits name default description 2:0 ignored 3'b000 these bits are ignored. 3 duart_stop_bit_len 1'b0 set for 2 stop bits, clear for 1 stop bit 4 duart_tx_cts_ena 1'b0 set to cause the transmitter to check cts, clear to ignore cts. channel a cts is on the s0_cts_tclkin pin and is also readable as ip[0]. channel b cts is on the s1_cts_tclkin pin and is also readable as ip[1]. 5 reserved 1'b0 always 0 7:6 duart_chan_mode 2'b00 channel mode. 0: normal 1: normal 2: local loopback 3: remote loopback 63:8 notimp 56?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 327 table 199: duart command registers duart_cmd_a - 00_1006_0150 duart_cmd_b - 00_1006_0250 bits name default description 0 duart_rx_en 1'b0 enable receiver. setting this bit at the same time as duart_rx_dis results in no change in the receiver. 1 duart_rx_dis 1'b0 disable receiver immediately (a character being received will be lost) setting this bit at the same time as duart_rx_en results in no change in the receiver. 2 duart_tx_en 1'b0 enable transmitter. setting this bit at the same time as duart_tx_dis results in no change in the transmitter. 3 duart_tx_dis 1'b0 disable transmitter when it next becomes idle (i.e. complete any in progress character) setting this bit at the same time as duart_tx_en results in no change in the transmitter. 6:4 duart_misc_cmd 3'b000 0: no action. 1: no action. 2: reset receiver. 3: reset transmitter. 4: no action. 5: reset channel's break-change interrupt. 6: start break (drive data output line low when the transmitter becomes idle, and prevent further transmission). 7: stop break (if currently sending a break, drive line high for at least one bit time and resume normal transmission). 7 reserved 1'b0 reserved, write as zero. 63:8 notimp 56?bx not implemented. table 200: duart status registers duart_status_a - 00_1006_0120 duart_status_b - 00_1006_0220 read only bits name default description 0 duart_rx_rdy 1'b0 receiver ready: at least one character can be read. this bit is set whenever there are characters in the receive fifo even if the receiver is disabled. 1 duart_rx_fful 1'b0 receive fifo full: if any further characters are received they will be discarded. this signal is asserted when the start bit is detected for the character that will cause the receiver to become full, if handshaking is disabled the cpu has one character-time to read data from the fifo before characters are lost. 2 duart_tx_rdy 1'b1 transmitter ready: there is room for at least one character to be written into the transmitter. this bit is set whenever there is space in the transmit fifo even if the transmitter is disabled (characters inserted in the fifo will be transmitted when the transmitter is next enabled). 3 duart_tx_emt 1'b1 transmitter empty: there are no characters to send and the transmitter is idle 4 duart_ovrun_err 1'b0 overrun error: this flag tags a received character to indicate that characters were lost prior to this one. 5 duart_parity_err 1'b0 parity error: this flag tags a received character to indicate that this character was received with incorrect parity bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 328 section 10: serial interfaces document 1250_1125-um100-r 6 duart_frm_err 1'b0 frame error: this flag tags a received character to indicate that this character (including parity bit) was non-zero and did not have a valid stop bit. 7 duart_rcvd_brk 1'b0 received break: this flag tags a received character (which will be zero) to indicate that a the start of a break was detected. 63:8 notimp 56?bx not implemented. table 200: duart status registers (cont.) duart_status_a - 00_1006_0120 duart_status_b - 00_1006_0220 read only bits name default description table 201: duart baud rate clock registers duart_clk_sel_a - 00_1006_0130 duart_clk_sel_b - 00_1006_0230 bits name default description 11:0 uart_clk_counter 12'h0 baud rate counter. this register sets the baud rate for both the transmitter and receiver. set to (100 mhz/(baud rate * 20))-1. 63:12 notimp 52?bx not implemented. table 202: duart full interrupt control registers duart_full_ctl_a - 00_1006_0140 duart_full_ctl_b - 00_1006_0240 bits name default description 3:0 duart_sig_full 4'hf this field sets the threshold for the receive fifo full interrupt. the interrupt is raised when the number of characters in the fifo is greater than the value set. with the default of 15 the interrupt is only raised when the fifo is completely full. 7:4 duart_int_time 4'h0 if this field is non-zero then the fifo full interrupt is raised if there are any characters in the receive fifo and the receive data line has been idle for duart_int_time * 16 bit times. if this field is zero the interrupt is never raised by a timeout. the timeout interrupt is cleared by any read of the rx_hold register. 63:8 notimp 56b'x not implemented. table 203: duart received data registers duart_rx_hold_a - 00_1006_0160 duart_rx_hold_b - 00_1006_0260 read only, read pops character from fifo bits name default description 7:0 rx_data 8'hx read only. received data. the character is only valid if the duart_rx_rdy bit is set in the status register prior to this register being read, when this register is read the next character is made available and its flag bits will be made available in the duart_status register. 63:8 notimp 56?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 329 table 204: duart transmit data registers duart_tx_hold_a - 00_1006_0170 duart_tx_hold_b - 00_1006_0270 write only bits name default description 7:0 tx_data w/o write only. data to transmit. writes will be ignored if the duart_tx_rdy bit is clear. 63:8 notimp 56?bx not implemented. table 205: duart input port register duart_in_port - 00_1006_0380 read only bits name default description this register gives the current value of the input port pins. 0 duart_in_pin0_val ext input pin level (0= low 1= high) ip[0] s0_cts_tclkin. 1 duart_in_pin1_val ext input pin level (0= low 1= high) ip[1] s1_cts_tclkin. 2 duart_in_pin2_val ext input pin level (0= low 1= high) ip[2] s0_cin_rclkin. 3 duart_in_pin3_val ext input pin level (0= low 1= high) ip[3] s1_cin_rclkin. 4 duart_in_pin4_val ext input pin level (0= low 1= high) ip[4] s0_tin. 5 duart_in_pin5_val ext input pin level (0= low 1= high) ip[5] s1_tin. 6 duart_rin0_pin ext input pin level (0= low 1= high) ip[6] s0_rin. 7 duart_rin1_pin ext input pin level (0= low 1= high) ip[7] s1_rin. 63:8 notimp 56?bx not implemented. table 206: duart input port change status register duart_inport_chng - 00_1006_0300 read only, read clears all change of state bits bits name default description port pins 3:0 duart_in_pin_val ext input pin level (0= low 1= high) ip[3:0]. these bits match duart_in_port[3:0]. 7:4 duart_in_pin_chng 4'b0 input pin change of state ip[3:0] 0= no 1= yes. these bits record whether any transitions were detected on the input pins since this register was last read. the bits are cleared when the register is read. 63:8 notimp 56?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 330 section 10: serial interfaces document 1250_1125-um100-r table 207: duart debug access input port change register duart_inport_chng_debug - 00_1006_03f0 read only, reads have no side effects bits name default description 7:0 debug these bits provide the same information as is in the duart_inport_chng register, but reads do not have side effects. 63:8 notimp 56b'x not implemented. table 208: duart input port change status register for channel a duart_inport_chng_a - 00_1006_03d0 read only, read clears channel a change of state bits bits name default description port pins 3:0 duart_in_pin_val ext input pin level (0= low 1= high) ip[3:0]. these bits match duart_in_port[3:0]. 7:4 duart_in_pin_chng 4'b0 input pin change of state ip[3:0] 0= no 1= yes. these bits record whether any transitions were detected on the input pins since this register was last read. bits 4 and 6 (the change of state bits for ip[0] and ip[2]) are cleared when the register is read. 63:8 notimp 56?bx not implemented. table 209: duart input port change status register for channel b duart_inport_chng_b - 00_1006_03e0 read only, read clears channel b change of state bits bits name default description port pins 3:0 duart_in_pin_val ext input pin level (0= low 1= high) ip[3:0]. these bits match duart_in_port[3:0]. 7:4 duart_in_pin_chng 4'b0 input pin change of state ip[3:0] 0= no 1= yes. these bits record whether any transitions were detected on the input pins since this register was last read. bits 5 and 7 (the change of state bits for ip[1] and ip[3]) are cleared when the register is read. 63:8 notimp 56?bx not implemented. table 210: duart output port control register duart_opcr - 00_1006_0370 bits name default description 0 reserved 1'h0 not used, always zero. 1 opc2_sel 1'h0 controls the s0_cout pin, when clear the pin is the complement of op[2], when set the pin outputs the 1x baud clock for the channel a transmitter. 2 reserved 1'h0 not used, always zero. 3 opc3_sel 1'h0 controls the s1_cout pin, when clear the pin is the complement of op[3], when set the pin outputs the 1x baud clock for the channel b transmitter. 7:4 reserved 4'h0 not used (no support for output bits 7:4). 63:8 notimp 56?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 331 table 211: duart per channel output control registers duart_opcr_a - 00_1006_0180 duart_opcr_b - 00_1006_0280 bits name default description 0 reserved 1'b0 reserved 1 opc_sel 1'b0 controls cout pin for the channel. an alternative access path for the corresponding bit in the duart_opcr . channel a: this controls the opc2_sel bit. channel b: this controls the opc3_sel bit. 7:2 reserved 6'b0 reserved 63:8 notimp 56b'x not implemented. table 212: duart aux control register duart_aux_ctrl - 00_1006_0310 bits name default description 0 duart_ip0_chng_ena 1'b0 ip[0] s0_cts_tclkin change of state enable. 1 duart_ip1_chng_ena 1'b0 ip[1] s1_cts_tclkin change of state enable. 2 duart_ip2_chng_ena 1'b0 ip[2] s0_cin_rclkin change of state enable. 3 duart_ip3_chng_ena 1'b0 ip[3] s1_cin_rclkin change of state enable. 7:4 reserved 4'h0 unused, always zero. 63:8 notimp 56?bx not implemented. table 213: duart per channel aux control registers duart_aux_ctrl_a - 00_1006_0190 duart_aux_ctrl_b - 00_1006_0290 bits name default description 0 duart_cts_chng_ena 1'b0 cts_tclkin change of state enable for the channel: channel a controls duart_ip0_chng_ena channel b controls duart_ip1_chng_ena 1 reserved 1'b0 reserved 2 duart_cts_chng_ena 1'b0 cin_rclkin change of state enable for the channel: channel a controls duart_ip2_chng_ena channel b controls duart_ip3_chng_ena 7:3 reserved 1'b0 reserved 63:8 notimp 56b'x not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 332 section 10: serial interfaces document 1250_1125-um100-r table 214: duart interrupt status register duart_isr - 00_1006_0390 read only bits name default description 0 duart_isr_tx_a 1'b1 transmitter ready 1 duart_isr_rx_a 1'b0 receiver ready / fifo full 2 duart_isr_brk_a 1'b0 change in break 3 duart_isr_in_a 1'b0 input port 0,2 changes status (input port changes for channel a) 4 duart_isr_tx_b 1'b0 transmitter ready 5 duart_isr_rx_b 1'b0 receiver ready / fifo full 6 duart_isr_brk_b 1'b0 change in break 7 duart_isr_in_b 1'b0 input port 1,3 changes status (input port changes for channel b) 63:8 notimp 56?bx not implemented. table 215: duart channel a only interrupt status register duart_isr_a - 00_1006_0320 read only bits name default description convenience register, only gives channel a isr 0 duart_isr_tx 1'b1 transmitter ready 1 duart_isr_rx 1'b0 receiver ready / fifo full 2 duart_isr_brk 1'b0 change in break 3 duart_isr_in 1'b0 input port 0 or 2 changes status 7:4 reserved 4'h0 reserved 63:8 notimp 56?bx not implemented. table 216: duart channel b only interrupt status register duart_isr_b - 00_1006_0340 read only bits name default description convenience register, only gives channel b isr 0 duart_isr_tx 1'b1 transmitter ready 1 duart_isr_rx 1'b0 receiver ready / fifo full 2 duart_isr_brk 1'b0 change in break 3 duart_isr_in 1'b0 input port 1 or 3 changes status 7:4 reserved 4'h0 reserved 63:8 notimp 56?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 333 table 217: duart interrupt mask register duart_imr - 00_1006_03a0 bits name default description bits in this register must be set to cause an interrupt to be generated when the corresponding bit in the duart_isr is set. 0 duart_imr_tx_a 1'b0 mask transmitter ready a 1 duart_imr_rx_a 1'b0 mask receiver ready / fifo full a 2 duart_imr_brk_a 1'b0 mask change in break a 3 duart_imr_in_a 1'b0 mask input port 0,2 change interrupt (input port changes for channel a) 4 duart_imr_tx_b 1'b0 mask transmitter ready b 5 duart_imr_rx_b 1'b0 mask receiver ready / fifo full b 6 duart_imr_brk_b 1'b0 mask change in break b 7 duart_imr_in_b 1'b0 mask input port 1,3 changes status (input port changes for channel b) 63:8 notimp 56?bx not implemented. table 218: duart channel a only interrupt mask register duart_imr_a - 00_1006_0330 bits name default description convenience register, only writes channel a imr bits 0 duart_imr_tx 1'b0 mask transmitter ready a 1 duart_imr_rx 1'b0 mask receiver ready / fifo full a 2 duart_imr_brk 1'b0 mask change in break a 3 duart_imr_in 1'b0 mask input port 0,2 changes status 7:4 reserved 4'h0 reserved 63:8 notimp 56?bx not implemented. table 219: duart channel b only interrupt mask register duart_imr_b - 00_1006_0350 bits name default description convenience register, only writes channel b imr bits 0 duart_imr_tx 1'b0 mask transmitter ready 1 duart_imr_rx 1'b0 mask receiver ready / fifo full 2 duart_imr_brk 1'b0 mask change in break 3 duart_imr_in 1'b0 mask input port 1,3 changes status 7:4 reserved 4'h0 reserved 63:8 notimp 56?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 334 section 10: serial interfaces document 1250_1125-um100-r table 220: duart output port set register duart_set_opr - 00_1006_03b0 write only bits name default description note: the output pins are the inverse of the op 0 duart_set_op[0] w/o op[0] 1= set to high 0= no change 1 duart_set_op[1] w/o op[1] 1= set to high 0= no change 2 duart_set_op[2] w/o op[2] 1= set to high 0= no change 3 duart_set_op[3] w/o op[3] 1= set to high 0= no change 7:4 reserved w/o reserved (only 4 outputs) 63:8 notimp 56?bx not implemented. table 221: duart output port clear register duart_clear_opr - 00_1006_03c0 write only bits name default description note: the output pins are the inverse of the op 0 duart_clr_op[0] w/o op[0] 1= clear to low 0= no change 1 duart_clr_op[1] w/o op[1] 1= clear to low 0= no change 2 duart_clr_op[2] w/o op[2] 1= clear to low 0= no change 3 duart_clr_op[3] w/o op[3] 1= clear to low 0= no change 7:4 reserved w/o reserved (only 4 outputs) 63:8 notimp 56?bx not implemented. table 222: duart output port rts register duart_out_port - 00_1006_0360 write only bits name default description note: the output pins are the inverse of the op / convenience register, for software rts control 0 duart_out_pin_set[0] w/o 0: no change 1: set output pin s0_rts_tstrobe to high (i.e. clear op[0]) 1 duart_out_pin_set[1] w/o 0: no change 1: set output pin s1_rts_tstrobe to high (i.e. clear op[1]) 2 duart_out_pin_clr[0] w/o 0: no change 1: clear output pin s0_rts_tstrobe to low (i.e. set op[0]) 3 duart_out_pin_clr[1] w/o 0: no change 1: clear output pin s1_rts_tstrobe to low (i.e. set op[1]) 7:4 reserved w/o reserved 63:8 notimp 56?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 335 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 336 section 10: serial interfaces document 1250_1125-um100-r s ynchronous m ode in synchronous mode, the serial data stream is acco mpanied by a clock and an optional gating or framing signal. there are two sub-modes, hdlc and transparent. in hdlc sub-mode, frames within the bit stream are recognized and processed according to iso/iec-3309 (high-level data link control (hdlc) procedures - frame structure). in transparent sub-mode, serial data is transmitted and received without modification. in both sub-modes, the serial stream can be qualified by a gating signal. typically, such gating would select a subset of the bits at the physical interface for internal processing. the gating signal can be provided externally. alternatively, it can be generated by a table-driven sequ encer that is synchronized to an external framing pulse. configuration options allow a choice of polarities and delays for the gating or synchronizing signals. the synchronous serial ports can operate at speeds of 0 to 55 mbp/s and thus can support up to t3, e3 and oc-1 data rates. in such applications, an external framer or similar interface would typically be used to connect to the serial line and would itself be controlled from the cpu via the generic bus interface (see section11: ?generic/boot bus? on page 361 ). each port is associated with a dma channel for transmit and another for receive. in synchronous mode, the port and the pair of dma channels are collectively called a serial channel. the interface provides two identical and independent serial channels, 0 and 1. the registers and interrupts associated with each are differentiated by appending _0 or _1 to their names. f unctional o verview the serial channels are part of the i/o subsystem on the part and connect to the zbbus through i/o bridge 1. figure 67 on page 337 shows a block diagram. each consists of 3 major functional blocks: a pair of built-in dma controllers with fifos a protocol engine that can operate in either hdlc or transparent mode a programmable line interface for each serial channel, there are two built-in dma controllers, one for transmit and one for receive. the dma controllers interface with the i/o bridge. they connect to the protocol engine via separate fifos for transmit (txfifo) and receive (rxfifo). except for the interpretation of link-specific option and status bits, which are summarized below, the serial dma channels function identically to those provided for the ethernet macs. note that each serial dma channel supports only a single chain or ring. for a full description of dma configuration and programming, refer to section7: ?dma? on page 147 . the line interface unit controls the signals connecting the part to external serial devices, which might range from codecs to simple line drivers to sophisticated external framers. the line interface is described in the next section. the protocol engine provides the link-level processing. it maps between dma?s byte streams and the line interface?s bit streams according to the selected protocol. section: ?framing parameters? on page 344 and section: ?hdlc transmitter? on page 344 describe its operation for the hdlc and transparent protocols respectively. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 337 figure 67: synchronous interface block diagram bus interface transmit fifo (8 x 64 bit i.e. 2 cache lines) receive fifo (16 x 32 bits i.e 2 cache lines) txpack rxpack (address matching) txbit (shifter, stuffing, pading, add/check crc) txcrc txflag (flag generation) txline txmem dout tin rxbit (shifter, check crc) rxstuff (de-stuffing) rxflag (remove flag/ abort) rxline rxmem din, rin txparam rxparam steering bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 338 section 10: serial interfaces document 1250_1125-um100-r l ine i nterface the line interface controls the flow of bits between the protocol engine and the external pins. in the receive direction it assembles a bit stream and clock for the protocol engine. in the transmit direction it fetches bits from the protocol engine and formats them for the line. the serial channels share pins with the duarts. each port can independently be configured for synchronous serial operation or for uart operation using reset time configuration resistors or by software (see section: ?reset? on page 26 ). when port 0 is configured for synchronous mode, it is connected to channel 0; similarly, port 1 to channel 1. the 8 pins for each interface are used as follows in synchronous mode. in addition, the following gpio pins can be driven from the serial port when the appropriate reset time configuration resistors select this use (see section: ?reset? on page 26 ). table 223: synchronous serial interface signal names pin direction synchronous serial port function dout output transmit data output cts_tclkin input transmit clock input tin input transmit enable or frame synch input rts_tstrobe output transmit strobe output din input receive data input cin_rclkin input receive clock input rin input receive enable or frame synch input cout output baud rate generator output note that the configuration must be set in the uart control block, in order for the baud clock to be output on this pin. table 224: synchronous serial interface gpio pins pin direction channel 0 channel 1 function rstrobe output gpio[0] gpio[1] receive strobe out user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 339 i nput l ine i nterface in the receive direction, data on pin din is sampled either by an external clock signal, supplied on the cin_rclkin pin, or by the internal baud rate generator. the internal baud clock can be made available externally on the cout pin by setting the appropriate bit in the duart_opcr register ( table 210 on page 330 ) in the uart control block. regardless of source, the polarity of the sampling clock edge is programmable. the clock configuration is done in the ser_clk register. there are three ways that data bits are qualified to determine if they should be accepted and sent as part of the bit stream to the protocol engine. 1 gapped clock : if the external device is supplying the clock on cin_rclkin, it can omit clock pulses. since the bcm1250 never receives a clock pulse this method can always be used to suppress the reception of bits. 2 external enable : regardless of clock source, the rin pin can be supplied with an externally generated enable signal. this can qualify the current data bit or may be delayed by 1, 2 or 3 clocks. 3 internal sequencer : regardless of clock source, but exclusive with (2), the enable signal can be generated by an internal sequencer, which is itself synchronized to the data stream by a pulse on rin. the sequencer can also provide a strobe on the rstrobe output. the bit stream delivered to the protocol engine consists of the bits sampled during the enabled bit times; clock edges occurring during disabled bit times are suppressed and not seen by the protocol engine. input using an external enable an external enable signal can be provided on the rin pin. this can be configured to be active high or low, and indicates valid data when active. the data (on din) and enable (on rin) are latched on the same edge of the clock. in the simplest case the enable qualifies the data bit that is latched at the same time, but the enable can also be delayed to qualify the data 1, 2 or 3 clocks later. figure 68: example reception using rin as active high enable (sampling on the falling clock edge) the example in figure 68 shows data and an active high enable being latched on the falling edge of the clock. the enable becomes inactive during cycle 0. if the enable delay is set to 0 then the data bit at time 0 will be ignored and the others will be accepted. if the enable delay is 3, the data bit at time 3 is skipped, while data bits at times 4, 5 and 6 are accepted (the example does not show the falling edges of cycles -3, -2, and -1 so it is not possible to determine from this figure if the data at bit times 0, 1, or 2 will be accepted). clock time: din rin/en 0123 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 340 section 10: serial interfaces document 1250_1125-um100-r the enable signal is level sensitive when used to enable the data. in transparent mode (see section: ?operation in transparent mode? on page 348 ) the enable signal is used to frame the data, this can be selected as being edge (inactive to active) or level based, but only the edge based framing is likely to be useful. rstrobe is not used when the interface is used for an external enable. it is best to configure the pin as a gpio. if the pin is configured as rstrobe it will remain deasserted. input using the internal sequencer an internal sequencer can be used to qualify received data bits. a user-configured table is used to generate the internal enable signal and an optional external strobe signal. an external framing pulse provided on the rin pin is used to synchronize traversal of the table with the data stream. the table consists of up to 16 entries, each with the format shown in table 225 . each entry controls the behavior of the line interface for a number of bit times equal to count+1 if bit/byte is 0, or to 8*(count+1) if bit/byte is 1. during those bit times, din is sampled and processed on each clock edge if enable is 1; din is ignored and no data is sent to the protocol engine if enable is 0. if the rstrobe pin is enabled then it will be driven with the value of strobe bit in the entry. the synchronization pulse on rin is latched on the same clock edge as the data on din. the synchronization pulse is delayed by 0, 1, 2 or 3 clocks. the edge_det bit in the ser_mode register selects either the active level or the inactive to active edge of the delayed pulse as the start signal for the sequencer. if the sequencer is currently idle it will reset to map table entry zero when started, and the enable bit in that entry becomes effective immediately. table entries are thereafter proces sed in order until encountering an entry with the last indicator set. after the last entry of the table is processed, the line interface unit waits for the next assertion of delayed rin before it restarts with entry 0. during any interval between the end of the table and reassertion of rin, din is not sampled. once the table scan has started the start signal is ignored. if an active level or edge is detected on the delayed rin signal it will be flagged as an rx_sync_error in the ser_status register and it will not affect the sequencer. (this may not be an error on some interfaces, for example if the sync is marked as level sensitive but lasts more than one cycle.) table 225: sequencer table entries bits name description 0 last indicates current entry is the last entry of the table. 1 bit/byte 0: bit 1: byte. 5:2 count one less than the number of bits/bytes controlled by this entry 6 enable enables reception of the current data bit. 0: disable 1: enable 7 strobe selects the value put on the external strobe pin while this entry is in use. the ser_mode register is used to select if the strobe is active high or low. 0: deassert 1: assert user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 341 the example in figure 69 shows an active high sync pulse. if the delay is 0, map entry 0 determines whether data bit 0 is accepted or rejected. if that entry spans a single bit time, map entry 1 controls the disposition of bit 1. alternatively if the delay is configured as one and entry 0 spans 14 byte times, it determines the treatment of bits 1 through 112. figure 69: example reception using rin as active high sync (sampling on the falling clock edge) o utput l ine i nterface in the transmit direction, data is driven on pin dout either by an external clock signal, supplied on the cts_tclkin pin, or by the internal baud rate generator. the internal clock can be made available externally on the cout pin if enabled by setting bit 1 (channel 0) or bit 3 (channel 1) in the uart output port configuration register ( duart_opcr ). the polarity of the transitioning clock edge is programmable. the dout pin will be high impedance while the interface is disabled, so a pull-up may be required. the output bits are optionally gated by means similar to the input: 1 gapped clock : if the external device is supplying the clock on cts_tclkin, it can omit clock pulses. since the bcm1250 never receives a clock pulse this method can always be used to suppress the transmission of bits. 2 external enable : regardless of clock source, the tin pin can be supplied with an externally generated enable signal. this is latched on the active edge of the clock and disables output 0, 1, 2 or 3 clocks later. the dout pin is high impedance (undriven) when disabled. 3 internal sequencer : regardless of clock source, but exclusive with (2), the enable signal can be generated by an internal sequencer, which is itself synchroniz ed to the data stream by an edge or level on tin. the sequencer can also provide a strobe on the tstrobe output. the bit stream from the protocol engine is output on the dout pin on every enabled clock edge. during cycles where the output is disabled dout is tri-stated following the clock edge and will be driven again following an enabled clock edge. output using an external enable the external enable on the tin pin can be configured to be active high or low. the signal is delayed by 0 to 3 clock edges. if the delay is zero then the output is immediately enabled and will drive the current output data, provided the enable signal is still asserted on the next active edge of the clock the data will change and new data will be output. if the delay is nonzero the enable is sampled on the same edge of the clock that is used to drive dout. tin must be stable for at least a set-up time prior to that clock edge (in the usual case it will transition on the opposite edge). when output is disabled, dout is tri-stated, and the bit stream supplied by the protocol engine does not advance. clock time: din rin/sync 0123 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 342 section 10: serial interfaces document 1250_1125-um100-r the tstrobe pin is used as a data valid indicator when an external enable is used. the strobe_active bit in the ser_mode register sets the active level that tstrobe will have when dout is valid. if the tin enable signal is always active (or is only changed between packets) then tstrobe will frame the packet. the protocol engine will ensure there is at least one bit time of gap between packets. in the example in figure 70 tin is sampled on the rising edge of the clock and dout changes as a result of the rising edge of the clock. the delay is set to 1 so the enable is sampled on the rising clock edge. since the enable is removed at the start of cycle 0 and 2, dout is tri-stated during bit times 0 and 2 and driven during bit times 1 and 3. (a similar figure would result if the delay is 3, removal of the enable during cycle 0 and 2 will result in dout being tri-stated during bit times 2 and 4 and driven at times 3 and 5). figure 70: example transmission using tin as active high enable (driving/sampling on rising clock edge) output using the internal sequencer the transmitter has its own serial sequencer and its own table for generating the enable signal. the table is used to generate the internal enable signal and an external strobe signal. an external framing pulse provided on the tin pin is used to synchronize traversal of the table with the data stream. the table consists of up to 16 entries, each with the same format as the receive table shown in table 225 on page 340 . each entry controls the behavior of the line interface for a number of bit times equal to count+1 if bit/byte is 0, or to 8*(count+1) if bit/byte is 1. during those bit times, data is accepted from the protocol engine and sent on dout on each clock edge if enable is 1; dout is set high impedance and no data is extracted from the protocol engine if enable is 0. the tstrobe pin is driven with the value of strobe bit in the entry. the synchronization pulse on tin is delayed by between 0 and three active edges of the clock. the edge_det bit in the ser_mode register selects either the active level or the inactive to active edge of the delayed pulse as the start signal for the sequencer. if the delay is zero the sequencer is immediately signalled to start (and the data and enable outputs will transition accordingly) the sequencer will start synchronously to the first, second or third clock edge after the synchronization event. if the sequencer is currently idle it will reset to map table entry zero when started, and the enable bit in that entry becomes effective immediately. table entries are thereafter processed in order until encountering an entry with the last indicator set. after the last entry of the table is processed, the line interface unit waits for the next start signal from the delayed tin before it restarts with entry 0. during any interval between the end of the table and reassertion of tin, dout is high impedance. once the table scan has started the start signal is ignored. if an active level or edge is detected on the delayed tin signal it will be flagged as a tx_sync_error in the ser_status register and it will not affect the sequencer. (this may not be an error on some interfaces, for example if the sync is marked as level sensitive but lasts more than one cycle.) clock time: tin/en dout 0123 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 343 the example in figure 71 has the sync pulse set at time 0. the map table will be reset to entry 0 after the configured delay and then determine when dout is driven. in the example the delay is one (sync is sampled on the clock edge) and the data is driven for at least the first four bit times. figure 71: example transmission using tin as active high sync (transition/sampling on rising clock edge) s ynchronous s erial p rotocol e ngine the protocol engine converts between the bit streams used by the line interface and the packets transferred by the dma engines. it has two modes, configured in the ser_mode register. in hdlc mode frames are encoded on the bit stream using the hdlc protocol. in transparent mode the bit stream is packed into bytes and the framing is based on the line interface enable signal. o peration in hdlc m ode in the hdlc mode the frame structure used by the dma engines is converted into the hdlc form on the line. the protocol engine can perform the following functions: insertion and deletion of hdlc flags bit stuffing and de-stuffing crc calculation and checking address filtering (optional) frame length checking - padding of short frames to a configured minimum frame size (optional) table 226 shows the hdlc frame structure (lengths in bytes). clock time: tin/sync dout 0123 table 226: hdlc frame structure flag (u) (01111110) address (1 to 2) control/data (1 to max) crc (2 or 4) flag/abort (1) (01111110) or (01111111) bit stuffed bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 344 section 10: serial interfaces document 1250_1125-um100-r the address, control and data fields are of variable length. the lengths and formats of addresses vary among the various link-level protocols that use bit synchronous hdlc-like framing, but lengths of 0, 1 or 2 bytes are typical. a crc is appended on transmission and is checked on reception. the crc can be either 16 bits or 32 bits. the ccitt crc algorithms are used. the generator polynomials are: crc-ccitt: x 16 + x 12 + x 5 + 1 crc-32: x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x + 1 crc-32 is also known as crc-ccitt-32. both alternatives use a crc preset of all 1?s and send the resulting crc in complemented form. on the physical link, hdlc flags (8?b01111110) delimit frames. a flag must precede and follow the concatenation of the address, control, data and crc fields of a frame. bit-stuffing prevents any occurrence of the flag pattern within those fields; the transmitter inserts a 0-bit after any sequence of 5 consecutive 1?s, and the receiver performs corresponding 0 deletion. when the same flag terminates one frame and begins the next, it is called a shared flag. a configuration option controls the minimum number of additional flags between frames. during idle periods, the transmitter sends either consecutive flags or will send an idle as zero followed by fifteen 1s and then the output will go high impedance. consecutive flags are logically equivalent to a single flag and do not delimit frames of length 0. frames can also be terminated by hdlc abort or idle patterns (a zero bit followed by at least 7 ones). abort and idle termination are not distinguished by the receiver but are reported as aborted frames. bytes are sent and received in order of increasing address according to the system endian mode. within each byte, except for the crc, the least significant bit is sent or received first. framing parameters the parameters controlling the format of frames ar e set in various configuration registers. the ser_mode register selects the crc used, the minimum number of flags between frames, and the pattern sent on an idle line. the ser_minfrm_sz and ser_maxfrm_sz registers set the minimum and maximum frame size respectively. the minimum should be set to the smallest size permitted for the address, control and data fields prior to bit-stuffing. the maximum should be set to the largest size permitted for the total sizes in bytes of the address, control, data and crc fields prior to bit-stuffing. hdlc transmitter the user defines a frame to be transmitted by constr ucting the address, control and data fields in a dma buffer or chain of such buffers. for details of dma buffers and descriptors, see section7: ?dma? on page 147 . for transmit, the dma option flags shown in table 227 are supported. table 227: option flags for synchronous serial transmit channel transmit commands bits name default description 0 reserved 1'b0 reserved 1 append crc 1'b0 if this bit is set the computed crc will be appended to the packet. 2 append pad 1'b0 if this bit is set the packet will be padded to the minimum packet size. 3 abort 1'b0 if this bit is set the packet will be ended with an abort instead of a standard flag. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 345 in most applications, the protocol engine will compute and append a crc. if dma option append_crc is not set, the user can supply a crc as part of the dma buffer. when the number of empty entries in the txfifo exceeds a configurable threshold ( ser_tx_wr_thres ), the dma engine will begin to write frame data into the txfifo. the start and end of the frame are specially marked for the protocol engine. once the number of bytes transferred to the txfifo exceeds another configurable threshold (derived from ser_tx_rd_thres ) or the end of frame has been written to the txfifo, processing of the new frame by the protocol engine can begin. first the protocol engine ensures that a user-defined number of flags, set in the flag_num field of the ser_mode register, have been sent prior to the opening flag of the new frame. a flag_num of 4?b0 indicates that the closing flag of one frame can be reused as the opening flag for the next. the user frame is then read from the txfifo into the protocol engine. an opening flag is automatically prepended and bit-stuffing is performed on the bytes supplied by the dma. if the transmit module empties the txfifo but the user frame has not completed, an underrun error is reported in the tx_underrun bit in the ser_status register. when this occurs, the transmit module terminates the current frame with an abort sequence. it then begins to send flag or idle depending on the setting of flag_en. the value of ser_tx_rd_thres should be adjusted to minimize the likelihood of such underruns. during frame transmission, the protocol engine always calculates a crc, either the crc-ccitt or crc-32 as determined by the crc_mode bit in the ser_mode configuration register. the bit-stuffed crc is inserted before the closing flag if the append_crc option is set in the dma descriptor. the transmitted crc is always compared to the calculated crc. if the crc was automatically generated, the two necessarily match. if the crc was supplied by the user and it does not match the calculated one, a transmit crc error is reported in the tx_crcerrr bit of the ser_status register. in addition, the protocol engine keeps track of the number of bytes that are sent for the current frame. if the number of bytes provided in the user frame is smaller than ser_min_frm_sz and the append_pad option is set in the transmit descriptor, the protocol engine automatically adds zero padding to the user frame. when padding occurs, the protocol engine also appends its calculated crc. finally, a trailing flag is automatically appended to the bit-stuffed frame. if dma option abort was set, an abort is sent instead of the final flag. the serialized bit stream is passed to the line interface as allowed by the transmit gating signals. when output to that interface is disabled, the serial stream does not advance; no bits are discarded. the output bit stream is not otherwise aligned or correlated with transitions on pin tin, whether used directly as the enable signal or as synchronization for the serial sequencer. no status is returned upon completion of dma, but a serial dma interrupt may be requested by setting the interrupt or pkt_int option. crc and underrun errors set the flags tx_crcerr and tx_underrun_error in the ser_status register respectively. these flags are cumulative. if the corresponding bit in the ser_err_mask register is set, they also trigger a serial device interrupt. reading the ser_status register resets these flags to 0 and clears the interrupt condition. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 346 section 10: serial interfaces document 1250_1125-um100-r the transmitter can be temporarily paused (for example as the result of a flow control request) by writing the tx_pause bit in the ser_cmd register. this causes the transmitter to complete sending the current packet and then suspend operation until re-enabled. the next packet will wait in the txfifo while the transmitter is paused. the tx_pause_complete flag in the ser_status register will be set to acknowledge completion of a tx_pause command. the flag is set immediately if there is no packet in flight when the command is issued, otherwise it will be set when the end of the current packet is moved from the txfifo into the transmit module. when the transmit module is idle, either flag (octet sy nchronous) or idle (bit synchronous) can be sent onto the channel as configured by flag_en in the ser_mode register. hdlc receiver in hdlc mode, frames within the bit stream are self-identifying. the protocol engine monitors the input bit stream supplied by the line interface. frame recognition begins with a flag not followed by another flag, an abort or an idle. the receive module first removes any bit stuffing to extract the bytes of the frames delimited by the opening and closing flags. the first step in processing is frame filtering based on the hdlc address. the bit mask in the ser_addr_mask configuration register selects address bits from within the first two bytes following the opening flag of each frame. a frame is accepted if its masked address bits match any of the four address registers, ser_usr0_addr through ser_usr3_addr, under the same mask. otherwise the frame is rejected and not sent to the rxfifo. figure 72 shows the address matching logic. figure 72: frame address matching mask 2nd byte 1st byte usr0_addr 15 0 15 0 8 7 15 0 match match_usr0 match_usr1 match_usr2 match_usr3 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 347 setting ser_addr_mask to all zeros disables address filtering and allows reception of all frames. link protocols with single-byte addresses should specify masks with all zeros in the most significant byte (i.e. 16?h00ff). when the number of acceptable addresses is less than four, the remaining address registers should be filled with copies of a valid address. the recovered bytes of the address, control, data and crc fields of the frame are written, with bit-stuffing removed, into rxfifo. if the rxfifo becomes full in the middle of receiving a frame, the receive module discards all except the last word received when the full condition occurs. when space in the rxfifo subsequently becomes available, this last word held is written into the fifo with status overrun bit set. any frames for which an opening flag is received while the rxfifo is full are ignored and not reflected in any status bits. received frames are moved from the rxfifo to dma buffers in memory by the serial dma engine. the beginning and end of frame are specially marked by the protocol engine. dma transfer begins when the number of entries in the rxfifo exceeds a configurable threshold ( ser_rx_rd_thres ) or when an end of frame is available in the rxfifo. the packet is checked for errors during reception. indi cations of any errors are passed to the rxfifo and eventually written back into the dma descriptor status field. for each frame, the crc is computed using crc-ccitt or crc-32, as selected by the crc_mode in the ser_mode register. the computed crc is compared with the value in the packet. if the two do not match, crc_error is signaled to the rxfifo. a frame that terminates with an abort or idle sequence is forwarded to the rxfifo marked with an abort error flag. the receive module also checks for a frame with a length (excluding opening and closing flags) that exceeds the maximum length programmed in the ser_maxfrm_sz register. for such a frame, data up to the maximum length allowed is forwarded to the rxfifo with an indication of a long frame error. similarly, the receive module checks for a frame that is shorter than the minimum length programmed in ser_minfrm_sz and sends a short frame error when forwarding the data to the rxfifo. note that frames of zero length are not recognized as such; a sequence of consecutive flags is equivalent to a single flag for the purpose of delimiting frames. the receive module also checks for frames that are not-octet aligned, i.e., frames in which the number of bits between flags is not a multiple of 8 after any bit-stuffing is removed. these frames are forwarded to the rxfifo with octet_error set. the dribble bits are recorded in a final byte that is transferred and included in the reported frame length. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 348 section 10: serial interfaces document 1250_1125-um100-r upon completion of the dma transfer, any error indications forwarded through the rxfifo are reported as status bits in the first descriptor for the corresponding frame. table 228 lists the dma status bits that are used by the receiver?s serial dma channel. in addition, a cumulative error summary is maintained in the ser_status register. the receive errors are rx_crc_error, rx_abort, rx_octet_erro r, rx_longframe_error, rx_shortframe_error and rx_overrun error. when enabled by the corresponding bit in ser_err_mask, any set bit in ser_status generates a request for a serial device interrupt. reading the ser_status register sets all bits to zero and clears the interrupt condition. o peration in t ransparent m ode in transparent mode, bit streams are sent and received without modification. frames are not self-identifying, but a frame structure can be imposed on the bit stream by external synchronization signals. for both transmit and receive, serialization of each byte can be either leas t significant bit first or most significant bit first, according to the setting of msb_first in the ser_mode configuration register. bytes are transmitted and received in order of increasing address according to the system endian mode. in transparent mode, the following functions may be performed: address matching (optional) padding of short frames to a configured minimum frame size (optional) crc calculation and checking (optional) in transparent mode, the data is framed by implicit start and stop indications at the bit level. the details depend upon configuration of the line interface. table 228: status flags for synchronous serial receive channel receive status flags bits name default description 55:50 reserved 6'b0 reserved 56 crc_error 1'b0 this bit is set if the received packet has a bad crc. 57 abort 1'b0 this bit is set if the received packet ended with the abort flag. 58 octet_error 1'b0 this bit is set if the size of the received packet was not a multiple of 8 bits. 59 longframe_error 1'b0 this bit is set if the size of the received packet is bigger than the maximum frame size. 60 shortframe_error 1'b0 this bit is set if the size of the received packet is shorter than the minimum frame size. 61 overun_error 1'b0 this bit is set if the received packet overan the fifo and is therefore invalid. 62 good 1'b0 this bit is set if the received packet has no errors. 63 sop 1'b0 this bit is set to indicate the start of the packet and the other bits are valid. software should ensure this bit is clear when it sets up the descriptor, the dma controller will only set it when packet reception has been completed. note the last time-slot specified in the user-defined table should always be enabled. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 349 transmitter in transparent mode in transparent mode, the protocol engine does not perfor m bit-stuffing or flag/abort insertion. thus the dma abort option is ignored. the append_crc and append_pad options remain available. the tin signal is used as described in section: ?output line interface? on page 341 either as a level sensitive enable or to synchronize the table driven output sequence r. the transmit module will detect the start of packet indicator from the dma engine as data comes out of the txfifo and align it to the line. if tin is used as an enable, the edge_det bit in the ser_mode register selects if the start of a packet will be aligned with the next inactive to active edge of enable or the next active level (allowing packets to go our back-to-back). if tin is used as a synchronization pulse the start of a packet will be aligned with the first entry of the sequencer table being selected, which can be based on either the edge of the pulse or its level. these two rules ensure that packet boundaries in the dma stream get aligned with the frame boundaries used on the line. if there are any idle cycles while a new frame is being aligned the dout pin will be set high impedance. in other respects, operation is identical to operation of the transmitter in hdlc mode. receiver in transparent mode transparent mode operates similarly to hdlc mode except that neither flag detection/deletion nor removal of bit stuffing is performed. crc checking and address filtering remain available. note that since there is no way to disable the crc check, device drivers for protocols that do not have crcs must ignore the crc error flag (and therefore cannot use the good packet bit) in the dma descriptor status information. frames are delimited by transitions of the gating signals in each direction. if there are no transitions, transfers make no progress. if an external enable signal is used, it serves as an envelope delimiting the frame. the initial bit in the frame is the one in the first bit time after transition of the (optionally delayed) enable signal to its active level. the final bit in the frame is the bit preceding the opposite transition. if the serial sequencer is used, the table is traversed exactly once to delimit the frame. the synchronization pulse (optionally delayed) will start processing bits from entry zero of the table and mark the start of a new frame. the first bit in the received frame will therefore be the first bit that is enabled in the table. the final bit in the frame will be the last bit in the last entry of the table with the enable bit set, following reception of this bit the sequencer will suspend until the next sync pulse and the packet will be complete. a sync pulse that occurs during traversal of the table will be logged as an rx_sync_error in the ser_error register but is otherwise ignored. in other respects, operation is identical to operation of the receiver in hdlc mode. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 350 section 10: serial interfaces document 1250_1125-um100-r s ynchronous i nterface c onfiguration there are four sections that must be configured be fore a serial channel can be used. these are: general control, fifo control, protocol engine/line interface configuration and address filtering. in addition, the serial dma channels must be configured. at system reset, the transmit and receive modules in the serial link interface are both disabled. they can be individually enabled by writing to the ser_cmd register. note that the ser_cmd register is write-only. resetting the transmit/receive module will put it into disabled state and flushes the txfifo/rxfifo. however, configuration registers are not restored to their default values. configuration registers should be written only when the corresponding modules are disabled. these modules need to be enabled after a reset by writing ones to the receive/transmit enable fields in the ser_cmd registers. dma c onfiguration refer to section7: ?dma? on page 147 for configuring and initializing the serial dma channels. fifo c onfiguration txfifo is a 64 bit wide fifo with 8 entries. the ser_tx_wr_thres register sets the number of empty 64 bit entries that must be in the txfifo before it will request dma data. since the dma engine fetches in blocks of 32 bytes, this value must be set to 4 entries. to reduce the likelihood of txfifo becoming empty during transmission of a frame, ser_tx_rd_thres should be set to ensure a certain number of entries (8 bytes each) have been written before the protocol engine starts. rxfifo is a 32 bit wide fifo with 16 entries. the ser_rx_rd_thres register sets the number of valid entries that must be in the fifo to request emptying by dma. since the dma engine transfers in blocks of 32 bytes, this value should be set to 8 entries. txfifo and rxfifo can be enabled or reset using the ser_cmd configuration register controls. threshold values should only be changed when the corresponding fifo is reset. p rotocol e ngine c onfiguration the protocol engine is configured in the ser_mode register. in addition the receive address mask and filter must be set in the ser_addr_mask and ser_usr n _addr (n=0,1,2,3) registers. if address filtering is not required the mask should be set to zero and all frames will be received. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 351 l ine i nterface c onfiguration the line interface is configured in the ser_mode and ser_line_mode registers. on reset the clock source defaults to use the internal baud rate clock, ensuring that state is correctly cleared. since changes to the line mode register can change the clocking of the interface block care must be taken when it is written: all previous configuration requests must have completed before the ser_line_mode register is written, and no additional registers should be written until the ser_line_mode register write has complet ed. any requests that are in progress close in time to when the ser_line_mode register is written will have unpredictable results. the recommended way to safely change the ser_line_mode register is to first read the ser_mode register and use the result (or use a sync) then write the ser_line_mode register and read it back and again use the result. s ynchronous s erial i nterrupts the dma interrupts for each channel are combined with status interrupts, and made available in the ser_status register. bits in this register are masked by the ser_int_mask register and combined to generate the system interrupts 10 (for channel 0) and 11 (for channel 1). reading the ser_status register will clear all bits in it. for a description of dma interrupts associated with the serial channels, please refer to section7: ?dma? on page 147 . to allow debuggers non-intrusive access to the status register, it is also made available through the ser_status_debug register, which does not clear the status on read. s ynchronous s erial l oopback there are two loopback configurations in the synchronous serial port. in both cases the transmitter output is connected internally to the receiver input. the first configuration relies on external timing pulses and uses tin and rin as normal. the second configuration has tin always active and internally connects rin to the rtst_strobe output. these are shown in figure 73 . when the second loopback mode is used the line interface configuration for both tx and rx can be set to the values in table 229 on page 352 to allow a table driven loopback. figure 73: synchronous serial loopback connections enable data_out loopback_enable data_in 1 0 tout loopback_enable rin 1 0 loopback_strobe_mode t out r in d out d in bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 352 section 10: serial interfaces document 1250_1125-um100-r rmon c ounters the serial interface maintains some counters that are useful for gathering rmon statistics. the counters are all 16 bits wide apart from the byte counters which are 32 bits wide (but occupy two register slots). the registers may be cleared by software writing to them. if any counter overflows it will wrap to zero and continue to count. table 229: recommended line interface settings for loopback mode 2 field value sync_active 1'b0 sync_delay 2'b00 strobe_active 1'b0 edge_det 1'b0 table_en 1'b1 table 230: rmon counters number (offset from 00_1006_0000 ) counter description 0 _0 - 05c0 _1 - 09c0 tx byte (low) total number of bytes transmitted. (low 16 bits). 1 _0 - 05c8 _1 - 09c8 tx byte (high) total number of bytes transmitted. (high 16 bits). 2 _0 - 05d0 _1 - 09d0 rx byte (low) total number of bytes received. (low 16 bits). 3 _0 - 05d8 _1 - 09d8 rx byte (high) total number of bytes received. (high 16 bits). 4 _0 - 05e0 _1 - 09e0 tx underflow total number of transmit packets aborted due to fifo underflow. 5 _0 - 05e8 _1 - 09e8 rx overflow total number of receive packets dropped due to overflow. 6 _0 - 05f0 _1 - 09f0 rx error total number of packets received with errors (crc error, abort flag, or octet error). 7 _0 - 05f8 _1 - 09f8 rx addr fail total number of receive packets dropped due the address not matching. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 353 s ynchronous s erial r egister s ummary all configuration and control registers are 16 bits. table 231: serial mode configuration register ser_mode_0 - 00_1006_0500 ser_mode_1 - 00_1006_0900 bits name default descriptions data format related 0 crc_mode 1?b0 0: crc-ccitt. 1: crc-32. 1 msb_first 1?b0 0: transmit/receive lsb in each byte first. 1: transmit/receive msb in each byte first. this bit is only used in transparent mode. hdlc related 5:2 flag_num 3?b1 minimum number of flags sent between back-to-back frames if hdlc is enabled. a value of 0 indicates the trailing flag of the previous frame is used as the open flag of the next frame. 6 flag_en 1?b0 0: idle is sent when transmit module is idle. 1: flag is sent when transmit module is idle. 7 hdlc_en 1?b1 0: transparent mode. 1: hdlc encoding. loopback 8 loop_strobe 1?b0 loopback strobe mode. this configures the sync/enable inputs during loopback. 0: tin and rin are taken from the external source. 1: tin is always active and rin is internally connected to rtststrobe. 9 loop_data 1?b0 loopback enable. if this bit is set the din input be internally connected to the dout output to allow loopback testing. 15:10 reserved 6?bx reserved 63:16 notimp 48?bx not implemented. table 232: synchronous serial clock source and line interface mode register ser_line_mode_0 - 00_1006_0578 ser_line_mode_1 - 00_1006_0978 bits name default description 0 rx_clk_inv 1?b0 this bit controls the inverter on the receive clock. 0: not inverted (clock on rising edge). 1: inverted (clock on falling edge). 1 rx_clk_src 1?b0 receiver clock source. 0: internal clock, generated by the baud rate generator. 1: external clock from cin_rclkin pin. 3:2 rx_sync_delay 2?b0 number of clock delays between the frame sync/enable and the first bit of the frame. 4 rx_sync_active 1?b0 0: sync/enable is active high. 1: sync/enable is active low. 5 rx_strobe_active 1?b0 0: strobe in line interface is active high. 1: strobe in line interface is active low. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 354 section 10: serial interfaces document 1250_1125-um100-r 6 rx_edge_det 1?b0 [7:6]these two bits set the interface synchronization method. 00: external enable is used using level as frame start. 01: external enable is used, using edge as frame start. 10: internal table drives enable, sync is level sensitive. 11: internal table drives enable, sync is edge sensitive. 7 rx_table_en 1?b0 8 tx_clk_inv 1?b0 this bit contols the inverter on the transmit clock. 0: not inverted (clock on rising edge). 1: inverted (clock on falling edge). 9 tx_clk_src 1?b0 transmitter clock source. 0: internal clock, generated by the baud rate generator. 1: external clock from rclkin pin. 11:10 tx_sync_delay 2?b0 number of clock delays between the frame sync/enable and the first bit of the frame. 12 tx_sync_active 1?b0 0: sync/enable is active high. 1: sync/enable is active low. 13 tx_strobe_active 1?b0 0: strobe in line interface is active high. 1: strobe in line interface is active low. 14 tx_edge_det 1?b0 [15:14]these two bits set the interface synchronization method. 00: external enable is used using level as frame start. 01: external enable is used, using edge as frame start. 10: internal table drives enable, sync is level sensitive. 11: internal table drives enable, sync is edge sensitive. 15 tx_table_en 1?b0 63:16 notimp 48?bx not implemented. table 232: synchronous serial clock source and line interface mode register (cont.) ser_line_mode_0 - 00_1006_0578 ser_line_mode_1 - 00_1006_0978 bits name default description table 233: synchronous serial command register (write-only) ser_cmd_0 - 00_1006_0540 ser_cmd_1 - 00_1006_0940 bits name description 0 rx_en receive enable. when the receiver is reset, writing a one enables the receiver. 1 tx_en transmit enable. when the transmitter is reset or paused, writing a one enables the transmitter. 2 rx_reset receive reset. writing a one resets the receiver. this should only be done when the line is idle or being restarted, resetting an active interface can result in partial packet reception. writing this bit will only reset the state machines; configuration registers are not returned to their default values. 3 tx_reset transmit reset. writing a one resets the transmitter. this should only be done when the line is idle or being restarted, resetting an active interface can result in unpredictable data and strobe signals being generated. writing this bit will only reset the state machines; configuration registers are not returned to their default values. 4 reserved must be written as 0. 5 tx_pause transmit pause. writing a one causes the transmitter to pause at the end of the next packet. if the transmitter has no data it will stop immediately, otherwise it will continue sending until the next end of packet has been sent. the transmitter leaves any subsequent packet in the txfifo. when the transmitter is re-enabled (by writing a 1 to the tx_en bit) the next packet will be fetched from the txfifo and normal operation will continue. 15:4 reserved must be written as 0. 63:16 notimp not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 355 table 234: serial write threshold register ser_tx_wr_thres_0 - 00_1006_0568 ser_tx_wr_thres_1 - 00_1006_0968 bits name default description 3:0 thrsh 4?b100 number of free 64 bit entries the txfifo must have before it signals the dma that space is free. this must be set to 4 for normal operation. writing other values in this register is for broadcom use only. 15:4 reserved 12?b0 reserved 63:16 notimp 48?bx not implemented. table 235: serial transmit read threshold register ser_tx_rd_thres_0 - 00_1006_0560 ser_tx_rd_thres_1 - 00_1006_0960 bits name default description 3:0 thrsh 4?b100 number of filled 64 bit entries the txfifo must have before the protocol engine will start transmitting the frame. the fifo is only 8 entries, so setting bit [3] will result in unpredictable behaviou r. 15:4 reserved 12?b0 reserved 63:16 notimp 48?bx not implemented. table 236: serial receive read threshold register ser_rx_rd_thres_0 - 00_1006_0570 ser_rx_rd_thres_1 - 00_1006_0970 bits name default description 3:0 thrsh 4?b1000 number of valid 32 bit entries the rxfifo must have before it signals the dma to read data. this must be set to 8 for normal operation. 15:4 reserved 12?b0 reserved 63:16 notimp 48?bx not implemented. table 237: serial minimum frame size register ser_minfrm_sz_0 - 00_1006_0508 ser_minfrm_sz_1 - 00_1006_0908 bits name default description 15:0 size 16?b0 minimum frame size in bytes. 63:16 notimp 48?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 356 section 10: serial interfaces document 1250_1125-um100-r table 238: serial maximum frame size register ser_maxfrm_sz_0 - 00_1006_0510 ser_maxfrm_sz_1 - 00_1006_0910 bits name default description 15:0 size 16?hffff maximum frame size in bytes. 63:16 notimp 48?bx not implemented. table 239: serial dma enable registers ser_dma_enable_0 - 00_1006_0580 ser_dma_enable_1 - 00_1006_0980 bits name default description 0 rxdma_en 1'b0 receive dma channel enable. must be set to enable the channel. 3:1 reserved 3'b0 reserved 4 txdma_en 1'b0 transmit dma channel enable. must be set to enable the channel. 7:5 reserved 3'b0 reserved 63:8 notimp 56?bx not implemented. table 240: synchronous serial status register ser_status_0 - 00_1006_0588 ser_status_1 - 00_1006_0988 read only, read clears bits name description 0 rx_crcerr received frame with crc error. 1 rx_abort received frame terminated by abort or idle. 2 rx_octet_error received frame length not a multiple of 8 bits. 3 rx_longframe_error received frame longer than maximum size. 4 rx_shortframe_error received frame shorter than minimum size. 5 rx_overrun_error rxfifo overrun. 6 rx_sync_error received a sync before the end of the receive table. 7 reserved reserved 8 tx_crcerr sent frame with bad user-supplied crc. 9 tx_underrun_error txfifo underrun. 10 tx_sync_error received a sync before the end of the transmit table. 11 tx_pause_complete set when emptying of the txfifo has stopped because of a tx pause command (sets immediately if no packet is in flight when the command is given, otherwise set after the end of packet has been moved from the fifo to the transmitter). 15:12 reserved reserved 16 rx_eop_count set if the eop interrupt was raised as a result of the packet count being reached. 17 rx_eop_timer set if the eop interrupt was raised as a result of the packet timer triggered. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 357 18 rx_eop_seen set at the end of any packet transfer. it can be used during polling to determine if any packets have been transferred since the register was read (regardless of the setting of the int_pktcnt field). 19 rx_hwm set if the high watermark interrupt is raised. 20 rx_lwm set if the low watermark interrupt is raised. 21 rx_dscr set if the interrupt is triggered by a descriptor with the interrupt on packet end command. 22 rx_derr set if the controller ran out of descriptors during a packet reception. the channel will be stopped. software must disable and re-enable the channel to clear this fault. 23 reserved reserved 24 tx_eop_count set if the eop interrupt was raised as a result of the packet count being reached. 25 tx_eop_timer set if the eop interrupt was raised as a result of the packet timer triggered. 26 tx_eop_seen set at the end of any packet transfer. it can be used during polling to determine if any packets have been transferred since the register was read (regardless of the setting of the int_pktcnt field). 27 tx_hwm set if the high watermark interrupt is raised. 28 tx_lwm set if the low watermark interrupt is raised. 29 tx_dscr set if the interrupt is triggered by a descriptor with the interrupt on packet end command. 30 tx_derr set if the controller ran out of descriptors during a packet transmission. the channel will be stopped. software must disable and re-enable the channel to clear this fault. 31 tx_dzero set if a descriptor has a packet length of zero. the channel will be stopped. software must disable and re-enable the channel to clear this fault. 63:32 notimp not implemented. table 240: synchronous serial status register (cont.) ser_status_0 - 00_1006_0588 ser_status_1 - 00_1006_0988 read only, read clears bits name description table 241: serial status debug register ser_status_debug_0 - 00_1006_05a8 ser_status_debug_1 - 00_1006_09a8 bits name default description 31:0 status 32?b0 reading this register gives the same value as reading the ser_status register, but does not have the side effect of clearing the register. 63:32 notimp 32?bx not implemented. table 242: serial interrupt mask register ser_int_mask_0 - 00_1006_0590 ser_int_mask_1 - 00_1006_0990 bits name default description 31:0 mask 32?b0 setting a bit in this register enables generation of an interrupt when the corresponding status bit is set in the ser_status register. 63:32 notimp 32?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 358 section 10: serial interfaces document 1250_1125-um100-r table 243: serial address mask register ser_addr_mask_0 - 00_1006_0518 ser_addr_mask_1 - 00_1006_0918 bits name default description 15:0 mask 16?b0 each one bit selects the address bits in the received frame to be matched with corresponding bits in the address match registers. bits 7:0 correspond to the first byte of the frame; bits 15:8 to the second. set this to zero for no address filtering; set bits 15:8 to zero for single-byte address filtering. 63:16 notimp 48?bx not implemented. table 244: serial address match register ser_usr0_addr_0 - 00_1006_0520 ser_usr0_addr_1 - 00_1006_0920 ser_usr1_addr_0 - 00_1006_0528 ser_usr1_addr_1 - 00_1006_0928 ser_usr2_addr_0 - 00_1006_0530 ser_usr2_addr_1 - 00_1006_0930 ser_usr3_addr_0 - 00_1006_0538 ser_usr3_addr_1 - 00_1006_0938 bits name default description 15:0 addr 16?b0 the destination address to be matched in all bit positions selected by the ser_addr_mask register. bits 7:0 correspond to the first byte of the frame; bits 15:8 to the second. 63:16 notimp 48?bx not implemented. table 245: sequencer table entries ser_rx_table_0 [0..15] - 00_1006_0600..0678 ser_rx_table_1 [0..15] - 00_1006_0a00..0a78 ser_tx_table_0 [0..15] - 00_1006_0700..0778 ser_tx_table_1 [0..15] - 00_1006_0b00..0b78 bits name description 0 last indicates current entry is the last entry of the table. 1 bit/byte selects the multiplier for count to give the number of bit times described by this table entry. 0: bit 1: byte 5:2 count number minus 1 of bits/bytes controlled by this entry 6 enable enable the serial line interface for the number of bit times described by this entry. for receive, ignore din during disabled bit times. for transmit, tristate dout during disabled bit times. 0: disable 1: enable 7 strobe enable the output strobe for the number of bit times described in this entry. 0: deassert 1: assert 63:8 notimp not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 10: serial interfaces page 359 table 246: serial rmon counters ser_tx_byte_lo_0 - 00_1006_05c0 ser_tx_byte_lo_1 - 00_1006_05c0 ser_tx_byte_hi_0 - 00_1006_05c8 ser_tx_byte_hi_1 - 00_1006_05c8 ser_rx_byte_lo_0 - 00_1006_05d0 ser_rx_byte_lo_1 - 00_1006_05d0 ser_rx_byte_hi_0 - 00_1006_05d8 ser_rx_byte_hi_1 - 00_1006_05d8 ser_tx_underrun_0 - 00_1006_05e0 ser_tx_underrun_1 - 00_1006_05e0 ser_rx_overflow_0 - 00_1006_05e8 ser_rx_overflow_1 - 00_1006_05e8 ser_rx_errors_0 - 00_1006_05f0 ser_rx_errors_1 - 00_1006_05f0 ser_rx_badaddr_0 - 00_1006_05f8 ser_rx_badaddr_1 - 00_1006_05f8 bits name default description 15:0 count 16?b0 counter. any write will zero the count. 63:16 notimp 48?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 360 section 10: serial interfaces document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 361 section 11: generic/boot bus i ntroduction the generic bus is used to attach the boot rom and a variety of simple peripherals. eight regions of memory are defined, each has its own chip select line, data width and set of timing parameters. all accesses to the generic bus range are accepted by the bus controller, a secondary decode determines which chip select region is used or raises an error. at reset time the generic bus address/data lines are read by the part to set static configuration options, so weak pull-up or pull-down resistors should be put on the board (see section: ?reset? on page 26 for details of the configuration bits). o verview the generic bus is allocated a 767 mb block of the address space, from 00_1009_0000 to 00_3fff_ffff . accesses to this address space cause transfers to take place on the generic bus pins. eight regions are defined within the range by setting the base address and size of each region. each region has an external active low chip select line, and a set of registers that set the transfer width and timing. six of the eight chip select regions are entirely free for individual devices. one (io_cs_l[0]) is used for the boot flash/rom, and one (io_cs_l[6]) is used for the pcmcia device when it is enabled but is otherwise free. each region can be configured to use either a 32 bit multiplexed address/data bus or an 8 bit wide data bus and 24 bit wide address bus. after reset, region 0 is configured to map 4mb starting at the physical address location of the mips processor reset exception routine, 00_1fc0_0000 and ending at 00_1fff_ffff . selection of a 32 bit multiplexed or 8 bit non-multiplexed bus for the boot region is made using the reset-time configuration options. an additional reset option diverts accesses made to region 0 to the smbus interface 0 to allow boot code to be fetched from an smbus eeprom (see section: ?booting using an smbus eeprom? on page 412 ). the address range initially assigned to region 0 also covers the physical address range ( 00_1fd0_0000 to 00_1fd0_ffff ) that external pci devices can access through the expansion rom bar. the same rom could therefore hold the boot code and pci expansion code. the data width of each region that is configured for multiplexed address/data can be specified as 8-bit, 16-bit or 32-bit. when an access is made to a narrower region the generic bus interface logic will automatically perform repeated reads or writes and can transfer up to a cache line of data as a result of a single request. the generic interface is big endian, thus an 8-bit devi ce connects to the upper byte io_ad[31:24], a 16-bit device connects to the upper word io_ad[31:16], and a 32-bit device connects to the entire io_ad[31:0]. in non-multiplexed mode the data pins connect to the upper byte io_ad[31:24] and the address is provided on the lower three bytes io_ad[23:0]. the pcmcia bus and other little endian devices should have d[7:0] connected to io_ad[31:24] and d[15:8] connected to io_ad[23:16] to keep the even addressed byte lane lined up correctly (see section12: ?pcmcia control interface? on page 383 for full details on connecting pcmcia cards). an alternative way of putting this is that the upper byte io_ad[31:24] is always the byte at the lowest memory address. this is true regardless of the internal system endian; the generic bus interface logic takes care of any swapping that is required. in alternate 8 bit multiplexed mode the data is transferred on io_ad[7:0], allowing direct connection to peripherals that use an 8 bit multiplexed connection. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 362 section 11: generic/boot bus document 1250_1125-um100-r table 247 shows the byte lane correspondences for the generic bus. these are discussed in more detail in the sections that follow. c onfiguring a c hip s elect r egion the properties of a chip select region on the generic bus are configured by writing a set of registers. there are eight sets, denoted by having _0 to _7 appended to the register names used in this discussion. a ddress r ange the address range allocated to the generic bus is partitioned by configuring the base address and size of each region. the base address of the region always has bits [39:30] and [15:0] as zero, bits [29:16] are set in the io_ext_start_addr register. this allows the start address to be set on any 64kb boundary below 00_4000_0000 . if the start address is set below the base address of the generic bus range ( 00_1009_0000 ) the region is disabled. the region start address is subtracted from addresses as they pass through the bus interface, so each device sees a contiguous block starting from zero. the size of the region is set in the io_ext_mult_size register. the size of the region is 64kb * ( io_ext_mult_size +1). since only 12 bits of the register are valid, the minimum region size is 64kb, and the maximum size is 256mb. an alternative way of thinking about this is that the last address in the region has bits [39:30] all zero, bits [29:16] equal to io_ext_start_addr + io_ext_mult_size and bits [15:0] all ones. if the last address of the region is set above 00_3fff_ffff some of the region will not be accessible. table 247: byte lanes for the generic bus mode io_ad[31:24] io_ad[23:16] io_ad[15:8] io_ad[7:0] non multiplex d[7:0] a[23:16] a[15:8] a[7:0] multiplex: ale active be[3:0] a[27:24] a[23:16] a[15:8] a[7:0] multiplex: ale inactive / 8 bit device d[7:0] multiplex: ale inactive / 16 bit big endian device d[15:8] d[7:0] multiplex: ale inactive / 32 bit big endian device d[31:24] d[23:16] d[15:8] d[7:0] multiplex: ale inactive / 8 bit pcmcia d[7:0] ce1# multiplex: ale inactive / 16 bit pcmcia d[7:0] ce1# d[15:8] ce2# multiplex: ale inactive / 16 bit little endian devices d[7:0] d[15:8] multiplex: ale inactive / 32 bit little endian devices d[7:0] d[15:8] d[23:16] d[31:24] multiplex: ale inactive / alternate 8 bit device d[7:0] parity for byte lane (only on data, not address) io_adp[3] io_adp[2] io_adp[1] io_adp[0] multiplex: offsets i.e. a[1:0] +0 +1 +2 +3 byte enable: active low while ale active (valid for both reads and writes) io_ad[31] io_ad[30] io_ad[29] io_ad[28] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 363 c acheable a ccess b locking to provide protection against programming errors and prevent side effects from accidental speculative accesses through kseg0 and xkphys (see section section: ?cpu speculative execution? on page 16 ) cacheable reads may be blocked from being driven on the generic bus. this is done by setting the blk_cache bit in the io_ext_start_addr register. if this bit is set and a cacheable access is done to the region then the access will be blocked. this bit is clear by default and should be left clear for memory areas like the boot rom that are likely to be cached for performance. to avoid causing the cpu to take an imprecise error as the result of a bad speculative access, a data error is not raised when a read is blocked. the access is just logged. when a cacheable access is blocked: 1 no cycle is run on the generic bus. 2 for a read unpredictable data is returned, marked with the valid data return code. 3 the io_cacheable_blk bit in the io_interrupt_status register is set (but no interrupt is raised). this bit is cleared by a read of the register. 4 if the log is not locked (i.e. the io_error interrupt is deasserted) the address of the access gets logged in io_interrupt_addr0 and io_interrupt_addr1 . g eneric b us p arity a reset time system configuration option enables parity on the data portion of a transfer on the generic bus (not the address). this is provided on the io_adp[3:0] pins, which are available as gpio pins if generic bus parity is disabled. if parity is enabled for the system then each region can be configured in the io_ext_cfg register to have even, odd or no parity check. on read transactions from parity generating devices, the parity bit of each byte of the incoming data is latched at the same time as the data, and checked against the parity computed for the byte. if an error is detected, then the address and region of the error are logged, the io_rd_par_int bit is set in the io_interrupt_status register, the generic bus error interrupt is raised and the data is passed to the system bus marked with a bus error. the data must be passed to the system bus to terminate the read transaction, the error flag will prevent its use. the bus watcher in the scd (see section section: ?bus watcher? on page 64 ) will note the error flag and increment the bus_io_error count. if the data is returning to one of the cpus then the bus error exception will be raised (thus the cpu could be told about the error three times: the bus error exception, the bus watcher error interrupt and the interrupt from the generic bus controller). when parity is enabled for a region it will be generated for the data in writes and will be driven on the parity pins with the same timing that the data has. if the device sees a parity error on writes it is device dependent how it responds and how it reports the error. table 247 on page 362 shows how the io_adp pins match with the byte lanes. data with an uncorrectable error from the system bus will not be seen by the generic bus interface. the bus watcher will log and report the error. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 364 section 11: generic/boot bus document 1250_1125-um100-r b us w idth the data width for a region is set in the io_ext_cfg register. if a region is in multiplexed address/data mode it can be set to have a data bus 8 or 16 or 32 bits wide. regions using non-multiplexed mode must always be configured for 8 bit widths. the interface will pack or unpack data as required. the generic bus is always ordered in a big endian manner, so the lowest memory location is on io_ad[31:24]. if the region is configured as 16 bit wide the odd addresses will be on io_ad[23:16], for 32 bit regions io_ad[15:8] and io_ad[7:0] are added to carry the bytes with a[1:0] equal to 2 and 3. writes to the generic bus can be 1-8 bytes direct from the cpu, 1-32 bytes from an uncached-accelerated merge from the cpu or data mover, or 32 bytes when a cache line (which must be cacheable non-coherent) is moved. the interface will order these and align them so that they are written on the generic bus in ascending address order (this is useful when writing to fifos on generic bus devices). reads from the generic bus will similarly be broken down into requests that match the width of the region. again the requests for a single read will be made in ascending address order. if a multiplexed address/data bus is used then the upper four bits io_ad[31:28] are used during the address phase as byte lane enables. these active low signals are used when doing byte accesses to 16 or 32 bit regions, and for half-word accesses to 32 bit regions. the mapping from the byte enables to the byte lanes is shown in table 247 on page 362 . g eneric b us t iming the timing of the generic bus is configurable for each of the chip select regions. when multiple devices are connected, care must be taken to ensure that the timing for one device does not confuse other devices. the chip select signals and idle time between cycles will normally be sufficient to ensure this. internally all the timing is done with reference to the 100 mhz clock (this clock is also used by the smbus and serial interfaces). this clock will be output on the io_clk100 pin if enabled by the reset configuration resistor on io_ad[23]. in most cases the clock is not needed externally and the interface is run as an asynchronous one using the computed timings given in the hardware data sheet. there are two modes for timing cycles. in fixed cycle mode the timing of the access is entirely controlled by the generic bus interface based on the parameters in the configuration registers. in acknowledgement based mode a ready/busy signal from the device controls the length of the access. the mode and active sense of the ready/busy signal is programmed in the io_ext_cfg register. table 248 on page 365 shows the parameters that can be set to control the cycle time. the next four sections have timing diagrams that show how these parameters control the cycle. each timing diagram includes the io_ad timing for both multiplexed and non-multiplexed operation. on reset the parameters for the io_cs_l[0] region are suitable for a slow eprom or flash memory (the parameters for the other regions do not get useful defaults). the parameters are programmed into the io_ext_time_cfg0 and io_ext_time_cfg_1 registers and are expressed in cycles of the 100 mhz reference clock (i.e. multiples of 10ns). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 365 in the fixed mode, the cycle time is: ale_width + ale_to_cs + cs_width + 1 + idle_cycle in the acknowledgement mode the minimum cycle time is: ale_width + ale_to_cs + cs_width + rdy_smple + 1 + idle_cycle table 248: generic bus timing parameters name range (cycle = 10ns) io_cs[0] reset description ale_width 1 - 7 cycles 4 width of the address latch enable pulse. this signal is asserted for this number of cycles to indicate the start of the cycle, the address and byte enables are output at the same time this signal asserts and remain stable after io_ale deasserts (i.e. io_ale is suitable for use as the latch input of a flow through latch, or the clock input of a falling-edge clocked flipflop). ale_to_cs 1 - 3 cycles 2 delay from io_ale being deasserted until assertion of the io_cs_l line for the region addressed. cs_width 1 - 31 cycles 24 the width of the chip select assertion in fixed cycle mode. in acknowledgement mode the io_rdy line will not be sampled until this number of cycles have passed, but the chip select remains asserted until the io_rdy signal has been asserted and rdy_smple+oe_to_cs cycles have passed. rdy_smple 0 - 7 cycles 1 in acknowledgement mode this is the number of cycles from io_rdy asserting to io_wr_l or io_oe_l deasserting (and data being latched in a read access). the chip select remains asserted oe_to_cs additional cycles. idle_cycle 1 - 15 cycles 6 the number of cycles that the bus should be idle before the next io_ale. note that the cycle does not end until one cycle after the io_cs_l line has deasserted. ale_to_wr 1 - 7 cycles 7 the number of cycles from io_ale deassertion to io_wr_l assertion in a write cycle. wr_width 1 - 15 cycles 7 in fixed mode this is the number of cycles that io_wr_l is asserted in a write cycle. in acknowledgement mode this value is ignored and the io_wr_l strobe deassserts rdy_smple cycles after the acknowledgement. cs_to_oe 0 - 3 cycles 0 the number of cycles from io_cs_l assertion to io_oe_l assertion is a read cycle. oe_to_cs 0 - 3 cycles 0 in fixed timing mode this sets the number of cycles before io_cs_l deassertion that io_oe_l deasserts in a read cycle. in acknowledgement mode this sets the number of cycles between the strobe (io_wr_l or io_oe_l) deasserting and io_cs_l deasserting. io_timeout (in io_ext_cfg ) 1 - 255 us 8 the number of microseconds to wait for the device to assert io_rdy in acknowledgment mode before terminating the access and signalling a timeout bus error. if this parameter is set to zero the access will never be terminated with a timeout, so will hang if an acknowledgement is never provided. burst_width 0 - 3 cycles 2??b0 sets the number of cycles gap between a transfer in a burst transaction. the gap is two cycles larger than the value set in this field. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 366 section 11: generic/boot bus document 1250_1125-um100-r the reference point for the io_wr_l write strobe is the deassertion of io_ale, it is the responsibility of software to ensure that the assertion timing (and width in fixed cycles) places the strobe within the cycle timing. it is required that ale_to_wr >= ale_to_cs (cs_width + ale_to_cs) >= (wr_width + ale_to_wr) similarly, in acknowledgement mode the io_oe_l and io_wr_l timing is expected to assert the pulses before the io_rdy line is checked. it is required that cs_width >= cs_to_oe cs_width >= (ale_to_wr - ale_to_cs) failure to meet these assumptions will result in undefined behavior. f ixed c ycle r ead a ccess figure 74: fixed cycle read access a fixed read cycle has the simplest timing. the address is put out at the start of the cycle along with io_ale. in the non-multiplexed version the address remains stable until the end of the cycle and the data lines are high impedance until the device drives them. in the multiplexed form the address stays valid until io_cs_l asserts and the bus is turned around for data transfer. the read strobe io_oe_l is asserted with a delay (which may be zero) from io_cs_l and will deassert a fixed number of cycles (which may be zero) before io_cs_l. the write strobe io_wr_l remains deasserted for the entire cycle. cs_width ale_to_cs idle_cycle ale_width 1 cycle address data address data non muxed muxed parity clk100 io_ale io_ad[23:0] io_ad[31:24] io_ad[31:0] io_adp[3:0] io_cs_l[n] io_oe_l io_wr_l io_rdy cs_to_oe oe_to_cs user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 367 f ixed c ycle w rite a ccess figure 75: fixed cycle write access the fixed cycle write is the same as the fixed cy cle read, except io_oe_l remains deasserted and the ale_to_wr and wr_width parameters are used to set the assertion of the io_wr_l signal. the data is output on the io_ad lines with the assertion of chip select. wr_width ale_to_wr cs_width ale_to_cs idle_cycle ale_width 1 cycle address data address data non muxed muxed parity clk100 io_ale io_ad[23:0] io_ad[31:24] io_ad[31:0] io_adp[3:0] io_cs_l[n] io_oe_l io_wr_l io_rdy bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 368 section 11: generic/boot bus document 1250_1125-um100-r a cknowledgement r ead a ccess figure 76: acknowledge read access the start of an acknowledgement access is the same as a fixed cycle, however after io_cs_l is asserted and the cs_width interval has passed the io_rdy line is monitored. the io_rdy line is treated as an asynchronous signal, and therefore synchronized internally to the 100 mhz reference clock (if it fails to meet the rdy_setup time it may not be sampled until the next cycle) so it should be asserted for a minimum of 20 ns. once io_rdy has been asserted (to match the rdy_active control bit) and the rdy_smple delay has passed the data will be sampled and io_oe_l deasserted. zero to three cycles later, set by the oe_to_cs parameter, io_cs_l will be deasserted. if the device does not signal that it is ready within the timeout period then the read will be aborted, the timeout error status set, the io_error_int interrupt will be raised and unpredictable data flagged with a bus error will be returned. in the case where the peripheral is using the io_clk100 and can meet the setup and hold time for io_rdy the synchronizer may be bypassed. there will therefore be no delay in the acknowledgement reaching the generic bus state machine and it will take effect immediately. for a read if the rdy_smpl parameter is set to zero and the synchronizer is bypassed the data is latched by the same io_clk100 edge that the io_rdy is setup to and the io_oe_l will deassert following that clock edge (by the clock-to-out delay). rdy_smple ale_to_cs idle_cycle ale_width rdy_setup cs_width 1 cycle address data address data non muxed muxed parity rdy_active = 0 clk100 io_ale io_ad[23:0] io_ad[31:24] io_ad[31:0] io_adp[3:0] io_cs_l[n] io_oe_l io_w_lr io_rdy cs_to_oe oe_to_cs user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 369 a cknowledgement w rite a ccess figure 77: acknowledge write access the acknowledgement cycle write is the same as the read, except io_oe_l remains deasserted and the ale_to_wr parameter is used to set the assertion of the io_wr_l signal. the io_wr_l signal is deasserted rdy_smple cycles after the ready signal is sampled. the oe_to_cs parameter is used to set the number of cycles io_cs_l remains asserted after io_wr_l is deasserted. if the device does not signal that it is ready within the timeout period then the write will be aborted, the timeout error status set and the io_error_int interrupt will be raised. ale_to_wr rdy_smple ale_to_cs idle_cycle ale_width rdy_setup cs_width 1 cycle address data address data non muxed muxed parity rdy_active = 0 clk100 io_ale io_ad[23:0] io_ad[31:24] io_ad[31:0] io_adp[3:0] io_cs_l[n] io_oe_l io_wr_l io_rdy oe_to_cs bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 370 section 11: generic/boot bus document 1250_1125-um100-r b urst m ode a chip select region on the generic bus can be set in a burst mode. this allows faster throughput by only doing a single address cycle at the start of the burst. however, there are some restrictions when in burst mode. the burst operation is based on the standard cycle outlined in the previous sections. the start of the transaction is the same with the address asserted with io_ale. the chip select and strobe (io_oe_l or io_wr_l) are asserted and data transferred as normal. when the strobe deasserts (again with the normal timing) either there are no more transfers in the transaction and the access ends in the usual way, or the chip select remains asserted through an idle period of 2 or more cycles before the strobe reasserts for the next data. this is shown in figure 78 and figure 79 and summarized in table 249 . figure 78: generic bus burst read figure 79: generic bus burst write io_clk100 io_ale io_cs_l io_oe_l io_ad[31:0] io_rw adr d0 d1 d2 d6 d7 t0 t1 t2 t3 t3 t4 t5 t6 io_clk100 io_ale io_cs_l io_wr_l io_ad[31:0] io_rw adr d0 d1 d2 d6 d7 t0 t1 t2 t3 t3 t4 t5 t6 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 371 the additional burst_width parameter is used to specify the duration of the gap between transfers in a burst, to this is added 2 cycles. thus the fastest sequence for a cache line burst to a region configured for 32 bit bus width and with burst_width=0 and the other parameters at their minimum values is 5-3-3-3-3-3-3-3 (the initial 5 being ale_width, ale_to_cs and the first 3 cycle access), giving 32 bytes in 26 cycles. factoring in request and response buffering in the i/o bridge and generic interface, for multiple cache line transfers both reads and writes should achieve a little over 100 mbytes/s (reads will be slightly slower on parts with system revision < periph_rev3). the burst mode is enabled by setting the io_burst_en bit in the io_ext_cfg register. if this is done then all transactions to the region must be smaller than or a multiple of the data width of the region and any uncached accelerated transactions (merged writes from the cpu) must have contiguous byte enables. if this is not done then extra locations will be accessed during the transfer so the result could be unpredictable. the byte enables put out with the address are valid only for the first data transfer on the generic bus. in burst mode the acknowledgement mode may be used. for the fastest burst the rdy_smpl must be set to 0 and the cs_width equal to cs_to_oe. in addition the io_rdy signal should be made synchronous. this allows the interface to detect the io_rdy signal (and the data for reads) during the first cycle the strobe is asserted. in the read case the ready and data are sampled and the io_oe_l will be deasserted after one cycle. the ready signal should be held asserted for the remainder of the cycle to ensure the fastest burst (or can be deasserted to delay the remaining accesses). the chip select width can still be used to ignore the io_rdy signal, but this only applies to the first transfer in the burst (i.e. ready is ignored from the chip select assertion for the cs_width but then must be valid for the rest of the cycle). if the io_rdy detection is asynchronous the internal detection can be as much as two cycles behind the external signal; this does not pose a problem if the ready indication is only used to delay the first transfer in the burst and remains asserted through the rest of the burst, but if the io_rdy is going to be used for each transfer in the burst then burst_width will need to be at table 249: burst cycle summary ref duration (cycles) min duration (cycles) action t0 ale_width 1 ale asserted and address driven on io_ad t1 ale_to_cs 1 gap t2 rd : cs_to_oe wr : ale_to_wr - ale_to_cs 0 io_cs_l asserted, strobe remains deasserted. on write the data becomes valid based on chip select assertion. t3 rd : cs_width - cs_to_oe - oe_to_cs wr : wr_width 1 io_cs_l and strobe asserted, first data transfers. in acknowledgement mode this width is a minimum of cs_width + 1 + rdy_smpl, and will be more if the io_rdy is not asserted after the cs_width holdof period. repeat next two lines while there is more data t4 2 + burst_width 2 io_cs_l asserted, strobe deasserted. on write the new data becomes valid after 2 of the gap cycles. t3 rd : cs_width - cs_to_oe - oe_to_cs wr : wr_width 1 io_cs_l and strobe asserted, next data transfers. in acknowledgement mode this width is a minimum of 1 + rdy_smpl. end the cycle when there is no more data t5 rd : oe_to_cs wr : ((cs_width - wr_width) - (ale_to_wr - ale_to_cs)) 0 io_cs_l asserted, strobe deasserted. (optional gap). in acknowledgement mode oe_to_cs is used for both reads and writes. t6 1 + idle_cycles 2 io_cs_l and strobe deasserted, bus idle time passes and cycle ends bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 372 section 11: generic/boot bus document 1250_1125-um100-r least 1 (or more if the ready deasserts longer after the strobe). the rdy_smpl value may be used to widen the strobe if required. if the burst mode is selected with a non-multiplexed bus the address will not increment through the burst, it will remain at the start address of the burst for the entire access. e arly c hip s elect the chip select normally asserts ale_to_cs cycles after the io_ale deasserts. some peripherals will only take note of the io_ale when their chip select is asserted. the early_cs bit in the io_ext_time_cfg0 register can be set to support them. it causes the external chip select signal to be asserted at the same time as io_ale and remain asserted through the ale_to_cs delay and the normal chip select assertion time. internally the normal chip select timing is used for control of the cycle. b oot rom s upport after reset, chip select region 0 is configured to map 4mb starting at the physical address location of the mips processor reset exception routine, 00_1fc0_0000 . the timing parameters for the region are set for a slow (40 ns) address latch connected to a slow rom with 240 ns access time from chip select and output enable. the other configuration parameters are set based on the boot_mode configuration resistors as described in table 250 . the smbus boot modes still use the generic bus module. the smbus interface 0 protocol engine is placed under the control of the generic bus controller. rather than run a generic bus cycle to fetch 32 bits of data, a request is made to the smbus controller. the smbus interface can be returned to normal software control by clearing the boot_mode[1] bit (bit[18] in the system_cfg register), once this is done the behavior of chip select region 0 becomes undefined until the io_ext_cfg_0 , io_ext_time_cfg0_0 and io_ext_time_cfg1_0 registers have been written. table 250: generic bus configuration for each boot mode boot mode generic configuration comments 00 width = 32 bit / fixed timing / multiplexed a/d / no parity this gives the highest performance rom connection. 01 width = 8 bit / fixed timing / nonmultiplexed a/d / no parity if address bits [27:24] and the byte enables (on bits [31:28]) are not needed, this will work with an 8 bit rom connected for a multiplexed a/d bus. 10 width = 32 bit / acknowledgement mode / timeout disabled / access small eeprom using smbus these two boot modes use the smbus boot path described in section section: ?booting using an smbus eeprom? on page 412 . 11 width = 32 bit / acknowledgement mode / timeout disabled/ access large eeprom using smbus user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 373 g eneric b us e rrors there are five error conditions that will raise the io_bus_int interrupt. when the interrupt signal is raised the associated address, data and parity are stored and the interrupt cause recorded. the causes are: 1 a data parity error is detected on an access to a generic bus region. 2 an access is performed to an address in the generic bus range that does not match any of the configured regions. 3 an access is performed to an address that matches multiple regions. 4 a region is configured in acknowledgement mode and the external device does not signal ready within the time limit set in the timeout register. 5 a cacheable coherent access is made to the generic bus and in the response phase of the access an agent asserts both r_shd and r_exc to indicate it has a tag error and cannot resolve the ownership. error cases ( 2 ), ( 3 ), and ( 5 ) are detected early so that no external access is made. after an error has been signalled accesses to the generic bus may continue. however, if another error occurs before the previous interrupt was serviced by the cpu, it will be ignored. the interrupt will be cleared only when the io_interrupt_status register is read (a cacheable read of the register will not clear the interrupt). to ensure consistent data, software should therefore read the address, data and parity registers before this status register. in the acknowledgement mode, if the access times out because the device does not signal ready the current transaction will be aborted (in the case of burst mode, the rest of the burst will not be completed). if the access was a read then data marked with a bus error will be returned. the next request will then be serviced. when the timeout occurs, the latency from the timeout being detected on the external bus to the bus error being returned is unpredictable, and could be as high as 64k cycles of the io_clk100. d rive s trength c ontrol the output drive strength and internal slew rate may be set for all the general 3.3v outputs. this covers the generic bus, the serial ports, the smbus ports, the ethernet/packet fifo interfaces and the gpio pins. the drive strength effectively sets the number of transistors that will be used to switch the output. the drivers can be varied in 2ma steps from a nominal source/sink current of 2ma up to 8ma for low strength drivers and from 6ma to 12ma for high strength drivers. the slew rate can be varied from fast (recommended default) to slow in four steps. the drivers are grouped by function for se tting the drive strength, and into larger groups for setting the slew rate. the parameters are described in more detail in the hardware data sheet. the drive strength registers for all of the general 3.3v outputs are included in the generic bus configuration register region of the address space. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 374 section 11: generic/boot bus document 1250_1125-um100-r g eneric b us r egisters table 251: generic bus region configuration registers io_ext_cfg_0 - 00_1006_1000 io_ext_cfg_1 - 00_1006_1008 io_ext_cfg_2 - 00_1006_1010 io_ext_cfg_3 - 00_1006_1018 io_ext_cfg_4 - 00_1006_1020 io_ext_cfg_5 - 00_1006_1028 io_ext_cfg_6 - 00_1006_1030 io_ext_cfg_7 - 00_1006_1038 a write to any bit causes all bits to be written. bits name default description 0 rdy_active 1'b0 when low the io_rdy is active low (i.e. the device lets the line go low when it is ready), when high io_rdy is active high. 1 io_ena_rdy 1'b0 when high, the interface uses acknowledgement based access. (see also bit 0) 3:2 io_width_sel 2'h0 select the data width size. 2'b00: 1 byte width (default for _0 bootmode 01) 2'b01: 2 byte width 2'b10: alternate 8 bit width (mux on d[7:0]) 2'b11: 4 byte width (default for cs0 bootmode 00, 10, 11) 4 io_parity_ena 1'b0 when high, enable parity check. 5 io_burst_en 1'b0 when high the interface will use the burst mode to run each transaction. 6 io_parity_type 1'b0 when low even parity is used, when high odd parity is used. 7 io_nonmux 1'b0 when high the bus is used in non-multiplexed mode with ad[31:24] being 8 bits of data and ad[23:0] being 24 bits of address. if the io_width_sel is not set to 2'b00 (for 8 bits) then bus operation is unpredictable. for _0 , the default is 1 in bootmode 01 and 0 in other bootmodes. 15:8 io_timeout 8'h8 time out value. unit is 1 us. if this field is zero the access will never timeout. 63:16 notimp 48?bx not implemented. table 252: generic bus region size registers io_ext_mult_size_0 - 00_1006_1100 io_ext_mult_size_1 - 00_1006_1108 io_ext_mult_size_2 - 00_1006_1110 io_ext_mult_size_3 - 00_1006_1118 io_ext_mult_size_4 - 00_1006_1120 io_ext_mult_size_5 - 00_1006_1128 io_ext_mult_size_6 - 00_1006_1130 io_ext_mult_size_7 - 00_1006_1138 a write to any bit causes all bits to be written. bits name default description 11:0 io_mult_size 12'h0 size of the memory region in the multiple of 64kb. the region size is (io_mult_size + 1)*64kb 15:12 reserved 4'h0 reserved 63:16 notimp 48?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 375 table 253: generic bus region base address registers io_ext_start_addr_0 - 00_1006_1200 io_ext_start_addr_1 - 00_1006_1208 io_ext_start_addr_2 - 00_1006_1210 io_ext_start_addr_3 - 00_1006_1218 io_ext_start_addr_4 - 00_1006_1220 io_ext_start_addr_5 - 00_1006_1228 io_ext_start_addr_6 - 00_1006_1230 io_ext_start_addr_7 - 00_1006_1238 a write to any bit causes all bits to be written. bits name default description 13:0 io_start_addr 14'h0 bits [29:16] of start address of segment. if this address is outside the generic bus range then the region is disabled. 14 reserved 1?b0 reserved 15 io_blk_cache 1?b0 if this bit is set then cacheable accesses to this region will be blocked. 63:16 notimp 48?bx not implemented. table 254: generic bus region timing 0 registers io_ext_time_cfg0_0 - 00_1006_1600 (defaults for boot rom) io_ext_time_cfg0_1 - 00_1006_1608 io_ext_time_cfg0_2 - 00_1006_1610 io_ext_time_cfg0_3 - 00_1006_1618 io_ext_time_cfg0_4 - 00_1006_1620 io_ext_time_cfg0_5 - 00_1006_1628 io_ext_time_cfg0_6 - 00_1006_1630 io_ext_time_cfg0_7 - 00_1006_1638 a write to any bit causes all bits to be written. bits name default description 2:0 io_ale_width _0 3?h4 3'h1 width of io_ale. 3early_cs1'b0 if this bit is set the external chip select is asserted during the ale_width and ale_to_cs gap as well as at the normal time. note that this bit only affects the external signal, the timing follows the internal chip select asserting in the normal cycle. 5:4 io_ale_to_cs _0 2?h2 2'h1 chip select assertion after deassertion of io_ale. 7:6 burst_width 2'b0 sets the gap between data transfers during a burst. the actual gap is burst_width + 2. 12:8 io_cs_width _0 5?h18 5'h1 width of the chip select asserted. if the interface is in acknowledgement mode this is the number of cycles from io_cs_l being asserted before io_rdy will start to be checked. 15:13 io_rdy_smple 3'h1 number of clock cycles after the assertion of the acknowledgement is returned that the data is sampled into the interface. this is ignored if the interface is in fixed cycle mode. 63:16 notimp 48?bx not implemented bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 376 section 11: generic/boot bus document 1250_1125-um100-r table 255: generic bus region timing 1 registers io_ext_time_cfg1_0 - 00_1006_1700 (defaults for boot rom) io_ext_time_cfg1_1 - 00_1006_1708 io_ext_time_cfg1_2 - 00_1006_1710 io_ext_time_cfg1_3 - 00_1006_1718 io_ext_time_cfg1_4 - 00_1006_1720 io_ext_time_cfg1_5 - 00_1006_1728 io_ext_time_cfg1_6 - 00_1006_1730 io_ext_time_cfg1_7 - 00_1006_1738 a write to any bit causes all bits to be written. bits name default description 2:0 io_ale_to_write _0 3?h7 3'h1 assertion of write strobe after the deassertion of ale. 3 rdy_sync 1'b0 if this bit is clear the io_rdy input is an asynchronous input and will be internally synchronized so there is no need for the peripheral to meet the setup and hold specification on the signal. if this bit is set the synchronizer is bypassed, so the acknowledgement is detected earlier by the generic bus state machine, but the peripheral must meet the setup and hold time specification. 7:4 io_write_width _0 4?h7 4'h1 width of the write strobe 11:8 io_idle_cycle _0 4?h6 4'h1 number of idle cycles between back_to_back operations. 13:12 io_oe_to_cs 2'h0 number of cycles io_oe_l deasserts before io_cs_l deasserts. in acknowledgement mode this parameter is also the number of cycles between io_wr_l deasserts and io_cs_l deasserts. 15:14 io_cs_to_oe 2'h0 number of cycles between io_cs_l assertion and io_oe_l assertion. this parameter must be less than io_cs_width. 63:16 notimp 48?bx not implemented. table 256: generic bus interrupt status register io_interrupt_status - 00_1006_1a00 read only (read clears interrupt) bits name default description 7:0 io_cs_err_int 8'h0 indicates which of the 8 chip select regions have an error resulting in an interrupt. this field is only valid when one or more of bits [9], [10], [13], or [14] are set. 8 reserved 1'b0 not used, reads as zero. 9 io_rd_par_int 1'b0 when high, indicates parity error on read data from a parity enabled device. the address of the 32 bit word accessed will be put in the address log, the data in the appropriate part of the data log, and the parity in the appropriate part of the parity log. 10 io_timeout_int 1'b0 when high, indicates timeout has occurred on one of the io blocks. the address that was being accessed is put in the address log. 11 io_ill_addr_int 1'b0 when high, indicates an address referenced did not match any region. the address that was being accessed is put in the address log. 12 io_mult_cs_int 1'b0 when high, indicates multiple chip selects selected based on the address accessed. the address that was being accessed is put in the address log. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 377 13 io_cacheable_ blk 1?b0 when high, indicates that a cacheable access was blocked from a region that has the io_blk_cache bit set in its io_ext_start_addr register. the log contains the address of the blocked access. 14 io_coh_err 1?b0 when high indicates that a cacheable coherent access was made to the generic bus address space, but an agent indicated that it has a tag error and was unable to resolve ownership. the log contains the address of the failing access. 15 reserved 1?b0 reserved 63:16 notimp 48?bx not implemented. table 256: generic bus interrupt status register (cont.) io_interrupt_status - 00_1006_1a00 read only (read clears interrupt) bits name default description table 257: generic bus error data register 0 io_interrupt_data0 - 00_1006_1a10 read only bits name default description 15:0 io_int_data0 16'h0 this register contains bits 15:0 of the data containing the parity error or captured when the timeout expired. 63:16 notimp 48?bx not implemented. table 258: generic bus error data register 1 io_interrupt_data1 - 00_1006_1a18 read only bits name default description 15:0 io_int_data1 16'h0 this register contains bits 31:16 of the data containing the parity error or captured when the timeout expired. 63:16 notimp 48?bx not implemented. table 259: generic bus error data register 2 io_interrupt_data2 - 00_1006_1a20 read only bits name default description 15:0 io_int_data2 16'h0 this register contains bits 47:32 of the data containing the parity error or captured when the timeout expired. 63:16 notimp 48?bx not implemented. table 260: generic bus error data register 3 io_interrupt_data3 - 00_1006_1a28 read only bits name default description 15:0 io_int_data3 16'h0 this register contains bits 63:48 of the data containing the parity error or captured when the timeout expired. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 378 section 11: generic/boot bus document 1250_1125-um100-r 63:16 notimp 48?bx not implemented. table 260: generic bus error data register 3 (cont.) io_interrupt_data3 - 00_1006_1a28 read only bits name default description table 261: generic bus error address register 0 io_interrupt_addr0 - 00_1006_1a30 read only bits name default description 15:0 io_int_addr0 16'h0 this register contains bits 15:0 of the address causing the interrupt. 63:16 notimp 48?bx not implemented. table 262: generic bus erroraddress register 1 io_interrupt_addr1 - 00_1006_1a40 read only bits name default description 15:0 io_int_addr1 16'h0 this register contains bits 31:16 of the address causing the interrupt. 63:16 notimp 48?bx not implemented. table 263: generic bus error parity register io_interrupt_parity - 00_1006_1a50 read only bits name default description 3:0 io_int_parity 4'h0 this register contains the parity of the data that generated the error. 63:4 notimp 60?bx not implemented. table 264: output drive control register 0 io_drive_0 - 00_1006_1300 a write to any bit causes all bits to be written. bits name default description 1:0 io_slew0 2?b11 slew0 control for i/o groups a, b, c, d, e, f, g, h, j, k. 3:2 io_drv_a 2'b01 8ma group a drive strength control. high drive 6/8/10/12 ma. uses slew0. io_ad[31:0]. 5:4 reserved 2?b11 reserved 7:6 io_drv_b 2'b01 8ma group b drive strength control. high drive 6/8/10/12 ma. uses slew0. io_cs[7:0]. 9:8 reserved 2?b11 reserved 11:10 io_drv_c 2'b01 8ma group c drive strength control. high drive 6/8/10/12 ma. uses slew0. io_wr_l, io_oe_l, io_ale, io_clk100. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 379 13:12 reserved 2?b11 reserved 15:14 io_drv_d 2'b01 8ma group d drive strength control. high drive 6/8/10/12 ma. uses slew0. pc_en3v pc_ev5v pc_envpp gpio[15:12]. 63:16 notimp 48?bx not implemented. table 264: output drive control register 0 (cont.) io_drive_0 - 00_1006_1300 a write to any bit causes all bits to be written. bits name default description table 265: output drive control register 1 io_drive_1 - 00_1006_1308 a write to any bit causes all bits to be written. bits name default description 1:0 reserved 2?b11 reserved 3:2 io_drv_e 2'b01 8 ma group e drive strength control. high drive 6/8/10/12 ma. uses slew0. gpio[11:6], gpio[1:0]. 5:4 reserved 2?b11 reserved 7:6 io_drv_f 2'b01 8 ma group f drive strength control. high drive 6/8/10/12 ma. uses slew0. gpio[5:2]/io_adp[3:0]. 9:8 reserved 2?b11 reserved 11:10 io_drv_g 2?b01 4 ma group g drive strength control. low drive 2/4/6/8ma. uses slew0. sda0 scl0. 13:12 reserved 2?b11 reserved 15:14 io_drv_h 2?b01 4 ma group h drive strength control. low drive 2/4/6/8ma. uses slew0. sda1 scl1. 63:16 notimp 48?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 380 section 11: generic/boot bus document 1250_1125-um100-r table 266: output drive control register 2 io_drive_2 - 00_1006_1310 a write to any bit causes all bits to be written. bits name default description 1:0 reserved 2?b11 reserved 3:2 io_drv_j 2?b01 4 ma group j drive strength control. low drive 2/4/6/8ma. uses slew0. s0_dout s0_tout s0_cout. 5:4 reserved 2?b11 reserved 7:6 io_drv_k 2?b01 4 ma group k drive strength control. low drive 2/4/6/8ma. uses slew0. s1_dout s1_tout s1_cout. 9:8 io_slew1 2?b11 slew1 control for i/o groups l and q. 11:10 io_drv_l 2?b11 12 ma group l drive strength control. high drive 6/8/10/12ma. uses slew1. e0_mdio (f0_rxfc) e0_mdc (f1_txd0) e0_geno (f0_txc2) e1_mdio (f1_txd2) e1_mdc (f1_txd1) e1_geno (f1_txd6) e2_mdio (f1_rxfc) e2_mdc (f1_txd7) e2_geno (f1_txc2). 13:12 io_slew2 2?b11 slew2 control for i/o groups m and p. 15:14 io_drv_m 2?b11 12 ma group m drive strength control. high drive 6/8/10/12ma. uses slew2. e0_txen (f0_txc0) e0_txer (f0_txc1) e0_txd[7:0] (f0_txd[7:0]) e1_txen (f1_txd4) e1_txer (f1_txd5) e1_txd[7:0] (f0_txd[15:8]). 63:16 notimp 48?bx not implemented. table 267: output drive control register 3 io_drive_3 - 00_1006_1318 a write to any bit causes all bits to be written. bits name default description 1:0 io_slew3 2?b11 slew3 control for i/o groups n and r. 3:2 io_drv_n 2?b11 12 ma group n drive strength control. high drive 6/8/10/12ma. uses slew3. e0_tclko (f0_tclko). 5:4 reserved 2?b11 reserved 7:6 io_drv_p 2?b11 12 ma group p drive strength control. high drive 6/8/10/12ma. uses slew2. e1_tclko (f1_txd3). 9:8 reserved 2?b11 reserved 11:10 io_drv_q 2?b11 12 ma group q drive strength control. high drive 6/8/10/12ma. uses slew1. e2_txen (f1_txc0) e2_txer (f1_txc1) e2_txd[7:0] (f1_txd[15:8]). 13:12 reserved 2?b11 reserved 15:14 io_drv_r 2?b11 12 ma group r drive strength control. high drive 6/8/10/12ma. uses slew3. e2_tclko (f2_tclko). 63:16 notimp 48?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 11: generic/boot bus page 381 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 382 section 11: generic/boot bus document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 12: pcmcia control interface page 383 section 12: pcmcia control interface i ntroduction the part provides limited support for using pcmcia memory cards attached to the generic bus. the interface allows card insertion and removal to be detected, provides and removes power from the card, and allows reading and writing of memory and attribute space on the card. the interface does not directly support i/o cards. the standard was renamed in 1995, so pcmcia cards are more correctly know as 16-bit pc cards. since the interface discussed in this section refers only to the cards defined in the pcmcia standard release 2.1 the more popular name pcmcia is used in this document. the pcmcia interface connects as chip select region 6 on the generic bus (see section: ?configuring a chip select region? on page 362 ). the generic bus configuration registers are used to set the address mapping and access timing for the card. the additional control logic provides: the two card enable signals (ce1# and ce2#) required by a card with a 16 bit data path. detection of card insertion and removal (cd1# and cd2#), the vcc voltage requested by the card (vs1# and vs2#), card ready, and write protect state (wp). software control of the pcmcia reg# signal to select between accessing regular memory and attribute memory, and the card reset signal. outputs to control a supply of vcc and vpp to the card. vcc can either be controlled from software or automatically. power is automatically removed when the card is removed. interrupts raised to report card status changes. c onnecting a pcmcia s lot the pcmcia interface uses ten of the gpio pins to provide the additional support signals. in addition there are three dedicated pins that provide the card power enables (see section: ?using the power outputs? on page 392 for information on using these pins as general outputs if pcmcia is not used). the reset-time configuration resistor on generic address bit io_ad[16] must pull high to convert the gpio[15:6] pins to pcmcia use. for proper operation the gpio_input_invert register bits [15:6] must be left as zeros (their default state) to disable the input inverter on the pcmcia pins. operation of the pcmcia card is undefined if any of these bits are set, and if the voltage sense inputs are inverted the wrong vcc voltage could be supplied to the card. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 384 section 12: pcmcia control interface document 1250_1125-um100-r d irect c onnection of a m emory o nly c ard figure 80 shows the connections between the interface and the memory only pcmcia slot. chip select region 6 of the generic bus is configured in multiplexed mode and set for a 16 bit wide device. to allow hot-swap the card signals must be isolated from the generic bus. for the 26 address bits the buffering can be done by the address latch. for the data, a bidirectional buffer is needed. the databus connections for the pcmcia card reflect the little endian nature of the pcmcia bus and the big endian byte lane assignment on the generic bus. so data[7:0] of the pcmcia slot should connect via an isolation buffer to io_ad[31:24] and data[15:8] of the pcmcia slot should connect through a buffer to io_ad[23:16]. this allows use of both 8 bit and 16 bit cards. figure 80: example pcmcia slot connection pcmcia card slot sb-1250 26 oe lat 373 16245 io_ale io_ad io_cs_l[6] io_oe_l io_wr_l 16 a[25:0] d[15:8] oe# we# reg# wp cd1# cd2# vs1# vs2# ready reset vcc1 vcc2 vpp1 vpp2 pcmcia power switch (eg max1602) pc_wp pc_cd1_l pc_cd2_l2 pc_vs1_l pc_vs2_l pc_ready pc_reset pc_en5v pc_en3v pc_envpp pc_reg_l ce1# pc_ce1_l ce2# pc_ce2_l 3.3v 3.3v 3.3v 3.3v [31:16] d[7:0] [23:16] [31:24] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 12: pcmcia control interface page 385 since the interface inputs are 3.3v only, care must be taken to buffer inputs from the card if 5v cards need to be supported. a fet switch or translating buffer can be used to provide the voltage conversion from card outputs and to provide power-down isolation for card inputs . the card detect and voltage sense lines are only statically pulled down or not connected on the card, they do not need buffers but should be pulled up to 3.3v on the main board. the pcmcia card uses two card enable signals (ce1# and ce2#) to indicate which byte lane is being used in a transfer. the pcmcia control logic generates these from io_ce_l[6] based on the size of the transfer requested by the cpu and the data width that the cs6 region has been configured for. if the interface is 2 bytes wide then the bottom address bit is not used by the card and the card enable lines select which byte lane is used during byte accesses. if the interface is only 1 byte wide then pc_ce1_l is always used with the lowest address bit, and pc_ce2_l is never asserted. the pc_reg_l signal is used to select between accesses to attribute memory (reg# low on the card) and regular memory. it is entirely under software control. the pc_reset signal is asserted to reset the card, while the card is in place it is controlled by software but the signal (and corresponding bit in the pcmcia_cfg configuration register) will be set high when there is no card detected. the wp (write protect) and ready status signals from the card are monitored and made available to software. each of these signals has a transition detector and can raise the pcmcia_interrupt when they change. these signals have a 60ns glitch filter. the vs1# and vs2# voltage sense signals are monitored and made available to software, they have a 60ns glitch filter. these lines are static signals from the card, and are either not connected or passively pulled low on the card. they indicate the vcc that the socket requests when it is first powered up. the pcmcia card detect lines (cd1# and cd2#) are monitored by the hardware. a card is only considered inserted when these two signals are both low (physically these are near the two ends of the card socket and have shorter pins so they are the last pins to make contact). these signals have a 1 ms glitch filter. the (internal) card detect signal is the nor of the filtered version of these signals. the pcmcia_interrupt can be raised when the card detect status changes. there are three dedicated outputs used to enable power to the card. two of these (pc_en3v and pc_en5v) control vcc, and the third (pc_envpp) controls the vpp programming voltage. the power enable signals are forced to be deasserted when the two card detect signals indicate a card is removed or not present. this provides the auto power down feature when a card is extracted. table 268: source for pcmcia card enable signals io_width_sel configuration access size pc_ce1_l (data on io_ad[31:24]) pc_ce2_l (data on io_ad[23:16]) 00 - 1 bytes any io_cs_l[6] 1 01 - 2 bytes even byte io_cs_l[6] 1 01 - 2 bytes odd byte 1 io_cs_l[6] 01 - 2 bytes half -word io_cs_l[6] io_cs_l[6] bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 386 section 12: pcmcia control interface document 1250_1125-um100-r software can directly control the card power using three bits in the pcmcia_cfg register, each bit corresponds to one output. these signals should be connected to an external power switch that provides the card vcc. when either cd1# or cd2# is set these bits are forced to zero and writes are ignored (i.e. software is unable to supply power if there is no card, the pwr_ctrl bit in the pcmcia_cfg register can be set to keep this behaviour when pcmcia mode is disabled). when a card is inserted the card detect status change interrupt is used to alert the software. the state of the vs1# and vs2# signals is then read and software sets the appropriate configuration bits to power up the card. if the card is subsequently removed the power is automatically turned off (as described above) and the bits in the pcmcia_cfg register are again cleared to zero to prevent immediate application of power when a new card is inserted (this must be done to avoid providing the wrong voltage to the new card). alternatively, vcc power management can be done entirely in hardware. this is configured by setting the apron_en bit in the pcmcia_cfg register. when this bit is set, the hardware detects the vs1# and vs2# signals and will enable the requested power to the card. the following table summarizes the vcc power control options. this table includes the options for controlling the power enable output bits when the pcmcia mode is not selected at reset time (this is discussed below in section: ?using the power outputs? on page 392 ). table 269: pcmcia 3.3v and 5v vcc power enable truth table mode control bits input signals from pcmcia card software control bits in pcmcia_cfg card state power outputs reset ad[16] pcmcia mode enable pcmcia_cfg pwr_ctl bit cd1# gpio[12] cd2# gpio[13] vs1# gpio[14] vs2# gpio[15] apron cfg3v cfg5v pc_en3v pc_en5v 1 x 1xxx x x xnot inserted 00 1xx1xxxxxnot inserted 00 1x00xx000inserted off 00 1x00xx001inserted sw set 5v 01 1 x 0 0 x x 0 1 0 inserted sw set 3.3v 1 0 1 x 0 0 x x 0 1 1 inserted sw set both power matrix decodes 1 1 1 x 0 0 1 1 1 x x 5v requested and supplied 0 1 1 x 0 0 0 1 1 x x 3.3v requested and supplied 1 0 1 x 0 0 1 0 1 x x low-voltage x.xv requested none supplied 0 0 1 x 0 0 0 0 1 x x x.x/3.3/5v requested 3.3v supplied 10 0 1 1 x x x x x x non-pcmcia cd used forced off 00 0 1 x 1 x x x x x non-pcmcia cd used forced off 00 0 1 0 0 x x x 0 0 non-pcmcia cd used off 00 0 1 0 0 x x x 0 1 non-pcmcia cd used sw set 01 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 12: pcmcia control interface page 387 the vpp power is supplied under software control, but is always turned off when no card is inserted. note that the hardware does not check the write protect state, and will supply vpp to a write protected card. this is summarized in the table below, which again includes details of use of the output pin when pcmcia mode is not selected. 0 1 0 0 x x x 1 0 non-pcmcia cd used sw set 10 0 1 0 0 x x x 1 1 non-pcmcia cd used sw set 11 0 0 xxxx x 0 0non-pcmcia off 00 0 0 xxxx x 0 1non-pcmcia sw set 01 0 0 xxxx x 1 0non-pcmcia sw set 10 0 0 xxxx x 1 1non-pcmcia sw set 11 table 269: pcmcia 3.3v and 5v vcc power enable truth table (cont.) mode control bits input signals from pcmcia card software control bits in pcmcia_cfg card state power outputs reset ad[16] pcmcia mode enable pcmcia_cfg pwr_ctl bit cd1# gpio[12] cd2# gpio[13] vs1# gpio[14] vs2# gpio[15] apron cfg3v cfg5v pc_en3v pc_en5v note in the case of both pc_en5v and pc_en3v being asserted (which can only be done under software control) the pcmcia power switch will determine what voltage is actually applied. table 270: pcmcia vpp power enable truth table mode control bits input signals from pcmcia card software control card state power output reset ad[16] pcmcia mode enable pcmcia_cfg pwr_ctl bit cd1# gpio[12] cd2# gpio[13] wp gpio[11] pcmcia_cfg cfgvpp bit pc_vppen 1x1xxxnot inserted 0 1xx1xxnot inserted 0 1 x 0 0 1 0 write protected, vpp disabled 0 1 x 0 0 1 1 write protected, vpp enabled 1 1 x 0 0 0 0 writable, vpp disabled 0 1 x 0 0 0 1 writable, vpp enabled 1 0 1 1 x x x non-pcmcia, cd used, forced off 0 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 388 section 12: pcmcia control interface document 1250_1125-um100-r o ther pcmcia s ignals the memory only pcmcia slot includes two signals for indicating the status of a battery on the card (bvd1 and bvd2). if these are required they can be connected vi a a level translating buffer to gpio pins configured as inputs. an additional signal wait# is used on some cards to indicate that it needs to extend the access time to a transaction. this can be connected through a buffer (to protect the interface input from 5v pcmcia cards) to the generic bus io_rdy input. additional logic may be required to combine the signal with the ready or busy signals from other devices if other generic bus chip select regions use the acknowledgement based mode. if the wait# line is connected in this way and a card that does not support wait# is inserted, the interface can be switched to fixed timing mode to ignore the io_rdy signal and allow the card to be used. the i/o and memory pcmcia interface changes the use of some of the signals and adds some others. the ready pin becomes ireq#, an active low interrupt signal. this will work with the standard connection to pc_ready, and the pcmcia interrupt can be raised whenever the pin changes state regardless of it indicating the card is ready, or is interrupting. the wp pin becomes iois16#. this is used by the card to inform the host for a particular address if a 16 bit access is possible. the generic bus does not support this behavior, so for cards which need this (indicated in the tpce_io field of the cistpl_cftable_entry configuration tuple) either the interface must be configured for 8 bit only operations or a software restriction made to ensure only 8 bit accesses are done to registers that are 8 bits. the pcmcia spec ification indicates that on any card that has a mixture of 8 and 16 bit registers byte registers that are at an odd address can be read on the d[15:8] byte lane when ce2# is asserted, matching table 270 on page 387 . the iord# and iowr# signals have been added. these match oe# and we# but for accesses to i/o addresses. one method of generating these is with ex ternal logic that drives io_oe_l and io_we_l to either (oe#, we#) or (iord#, iowr#) based on an address bit. the pcmcia card does not share the generic bus region with other peripherals, so the input port acknowledgement signal inpack# is not needed. bvd2 is replaced by spkr#, which can be used to drive a beep speaker. this would go to some other block than the bcm1250 or BCM1125/h. bvd1 is replaced by stschng# which is used to indicate the card status has changed and the card pin replacement register should be read to get the values that would otherwise be reported on the ready, wp, bvd1 or bvd2 pins. 0 1 x 1 x x non-pcmcia, cd used, forced off 0 0 1 0 0 x 0 non-pcmcia, cd used, sw turned off 0 0 1 0 0 x 1 non-pcmcia, cd used, sw turned on 1 0 0 x x x 0 non-pcmcia, sw turned off 0 0 0 x x x 1 non-pcmcia, sw turned on 1 table 270: pcmcia vpp power enable truth table (cont.) mode control bits input signals from pcmcia card software control card state power output reset ad[16] pcmcia mode enable pcmcia_cfg pwr_ctl bit cd1# gpio[12] cd2# gpio[13] wp gpio[11] pcmcia_cfg cfgvpp bit pc_vppen user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 12: pcmcia control interface page 389 compactflash and cf+ cards have a similar interface to the pcmcia cards. they also support a trueide mode, which cannot be directly connected, but they are required to be able to work in the other modes so this should not be a problem. if only the memory mode of cf/cf+ cards is required then the interface is the same as the memory only pcmcia interface presented above. however, cf/cf+ cards must be able to operate at 3.3v so the voltage level translators can be avoided (in this case software will have to reject any cards that require 5v for full operation). u sing t he pcmcia c ard the generic bus address window scheme is used to map between the system address space and the pcmcia flash memory address space. the pcmcia cards are accessed through region 6 of the generic bus address space. the usual io_start_addr and io_multi_size registers are configured to set the base address that the card appears in the system address space and its size. the base address of the region will be mapped to address zero in the pcmcia space, so pcmcia card addresses can be computed by adding this offset. in addition the pcmcia_reg bit within the pcmcia_cfg register must be set according to whether the flash card's attribute or common memory is being accessed. this bit defaults to the low state which selects the common memory. the card timing is configured using the generic bus timing registers. since these default to being appropriate for the boot rom (see section: ?generic bus timing? on page 364 ) software should configure the timing in region 6 for pcmcia access at system startup. the first access to a card after power on should be an attribute memory read. the pcmcia_cfg_reg bit should be set to allow this. the transfer is 16 bits but only the even byte contains valid data because attributes are stored in even byte locations only. the initial attribute memory accesses should be used to extract details from the card information structure (cis). these details include the card identification and the timing parameters for the card (which will generally have a faster access time than the default). software should update the parameters for the generic bus region 6. once the cis has been read the pcmcia_cfg_reg bit can be cleared to allow access to the memory portion of the card. the pcmcia controller monitors status change events and generates an interrupt. the interrupt is cleared by reading the pcmcia_status register. an interrupt mask is provided so specific status change events can be masked out. the pcmcia controller supports 3 card conditions or events: card insertion or removal. card ready status change. card wp write protect state change. software can perform a card reset by setting the reset bit high inside the pcmcia_cfg control register. the flash card remains in reset until the reset bit is set low. the reset signal is set when the system powers up and when no card is detected. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 390 section 12: pcmcia control interface document 1250_1125-um100-r e xample pcmcia t imings a flash card might have the access timings given in table 271 . if such a card were connected as shown in figure 80 on page 384 possible generic bus timing parameters for this card are given in table 272 on page 392 . the timing diagram that results for read and write accesses is shown in figure 81 on page 391 . note that the values used for the card timing and the propagation delays of the buffers are chosen for illustration only and do not necessarily match any real devices. table 271: example flash card ac specs parameter name min (ns) max (ns) read cycle time trc 150 - address access time tacca - 150 card enable access time taccce - 150 output enable access time taccoe - 80 output disable time tdis - 50 write cycle time twc 150 - write pulse width twp 75 - address setup time to we tsua 20 - card enable setup time to we tsucewe 0 - address setup time to we end tsuaweh 140 - data setup time to we end tsud 50 - data hold time from we end thd 20 - card enable to we end tsuceweh 100 - card enable hold from we end thce 0 - write recover time trec 20 - user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 12: pcmcia control interface page 391 figure 81: example flash card timing diagram clk100 io_ale io_cs[6] ce1 ce2 a[25:0] io_ad(rd)[31:0] d(rd)[31:0] io_oe(rd) io_wr(rd) io_ad(wr)[31:0] d(wr)[31:0] io_oe(wr) io_wr(wr) asserted for low data byte asserted for low data byte asserted for high data byte asserted for high data byte address latched on ale enabled by io_cs[6] address latched on ale enabled by io_cs[6] t_ale_width t_ale_to_cs t_cs_width t_ce_to_oe t_oe_to_cs t_bus_idle taccoe 160ns taccce 160ns t_ale_to_wr t_wr_width tsucewe 70ns twp 80ns thce 20ns trc 220ns tsud 130ns tsuceweh 150ns tacca 155ns thd 20ns tsua 65ns tsuaweh 145ns tdis(part) trec 25ns bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 392 section 12: pcmcia control interface document 1250_1125-um100-r selection of most of the parameters is straight forward. for reads the chip select width controls the cycle and must be selected to be larger than the access time. in this case it is the tacca(max) that controls this. the chip select enables the address buffer, so the address only becomes valid after the output enable delay of the buffer (5ns in this case). the output disable time (tdis) sets the number of idle cycles. assuming the next cycle is a write (i.e. the data buffer will drive on the next io_cs[6]) there are two cycles or 20ns belonging to the next cycle that can be part of tdis (the cycle with io_ale asserted and the ale_to_cs delay), thus 30 ns or three cycles are needed in the current access (tdis(part) on the diagram). there is always one idle cycle so idle_cycle must be set to 2 to give the extra two idle cycles. there are many parameters related to the write pulse. the controlling ones are the write width (twp) which directly requires the wr_width to be 8, and the address to write deassertion setup time (tsuaweh). fortunately once these are set the data hold time is satisfied with the same chip select width as for the read. u sing the p ower o utputs if the pcmcia mode is not enabled by the reset time configuration resistor then the three power control lines can be controlled by software directly through the pcmcia_cfg register. if the pcmcia_cfg_pwr_ctl bit is set then the state of the gpio[12] and gpio[13] pins are used in the same way they would be (as cd1# and cd2#) in pcmcia mode. they must be low to allow software to set the power control output lines, and the bits in the pcmcia_cfg bits will be cleared if either goes high. this may be used in systems other than pcmcia that need to implement hot-swap logic. the pins remain gpio pins, if they are configured as outputs then the value being driven will be read back from the pin and used to control the power logic. table 269 on page 386 and table 270 on page 387 show the logic of the power control lines when pcmcia mode is disabled. table 272: example generic bus timing parameters parameter value ale_width 1 ale_to_cs 1 cs_width 17 cs_to_oe 0 oe_to_cs 0 ale_to_wr 8 wr_width 8 idle_cycel 2 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 12: pcmcia control interface page 393 pcmcia c ontroller r egisters the pcmcia controller is enabled at reset time by a selection resistor on the generic address bus. the state can be read from the system configuration register. the other pcmcia control registers are: table 273: pcmcia configuration register pcmcia_cfg - 00_1006_1a60 bits name default description 0 pcmcia_cfg_reg 1'b0 when high, selects attribute memory. the pc_reg_l pin is the inverse of this bit. 1 pcmcia_cfg_3v_en 1'b0 when high, 3 volt supply enabled. in pcmcia mode or if bit 9 is set this bit is set low whenever no card is detected. in non-pcmcia mode this pin allows software control of the en3v output. 2 pcmcia_cfg_5v_en 1'b0 when high, 5 volt supply enabled. in pcmcia mode or if bit 9 is set this bit is set low whenever no card is detected. in non-pcmcia mode this pin allows software control of the en5v output. 3 pcmcia_cfg_vpp_en 1'b0 when high, programming voltage enabled. in pcmcia mode or if bit 9 is set this bit is set low whenever no card is detected. in non-pcmcia mode this pin allows software control of the envpp output. 4 pcmcia_cfg_reset 1'b1 when high, apply reset to the pcmcia card. this bit is set when the system is reset or whenever no card is detected. 5 pcmcia_cfg_apron_en 1'b0 when high, enable auto power on. 6 pcmcia_cfg_cd_mask 1'b1 when high, disable card detect interrupt. when low an interrupt is raised whenever the cd1_l and cd2_l (gpio[13:12]) lines either become both zero or stop being both zero. (the pcmcia mode setting has no effect on this interrupt). 7 pcmcia_cfg_wp_mask 1'b1 when high, disable write protect interrupt. when low an interrupt is raised whenever a change is detected on the wp (gpio[11])line (the pcmcia mode setting has no effect on this interrupt). 8 pcmcia_cfg_rdy_mask 1'b1 when high, disable card ready interrupt. when low an interrupt is raised whenever a change is detected on the ready (gpio[9])line (the pcmcia mode setting has no effect on this interrupt). 9 pcmcia_cfg_pwr_ctl 1'b0 this bit is only used when the pcmcia function is not selected at reset time. when high, the pcmcia card detect inputs are used in driving the power select pins when pcmcia mode is not selected.. 15:10 reserved 7'h0 reserved 63:16 notimp 48?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 394 section 12: pcmcia control interface document 1250_1125-um100-r table 274: pcmcia status register pcmcia_status - 00_1006_1a70 read only, read clears interrupt bits name default description 0 pcmcia_status_cd1 ext this bit reflects the state of the card detect 1 signal (pc_cd1_l) from the pcmcia card. when both pc_cd1_l and pc_cd2_l are low the card is fully inserted. 1 pcmcia_status_cd2 ext this bit reflects the state of the card detect 1 signal (pc_cd1_l) from the pcmcia card. when both pc_cd1_l and pc_cd2_l are low the card is fully inserted. 2 pcmcia_status_vs1 ext this bit reflects the state of the voltage sense 1 signal (pc_vs1_l) from the pcmcia card. 3 pcmcia_status_vs2 ext this bit reflects the state of the voltage sense 2 signal (pc_vs2_l) from the pcmcia card. 4 pcmcia_status_wp ext this bit reflects the state of the write protect signal (pc_wp) from the pcmcia card. when high, write protect is enabled. 5 pcmcia_status_rdy ext this bit reflects the state of the ready signal (pc_ready) from the pcmcia card. when high, indicates the card is ready for access. 6 pcmcia_status_3v_en 1'b0 when high, indicates 3 volt vcc is enabled. this bit reflects the value driven on the pc_en3v signal. 7 pcmcia_status_5v_en 1'b0 when high, indicates 5 volt vcc is enabled. this bit reflects the value driven on the pc_en5v signal. 8 pcmcia_cd_change 1'b0 this bit is set when either of the card detect signals change. it is cleared by a read. if this bit is set an interrupt will be raised if it is not masked in the pcmcia_cfg register. 9 pcmcia_wp_change 1'b0 this bit is set when the write protect signal changes. it is cleared by a read. if this bit is set an interrupt will be raised if it is not masked in the pcmcia_cfg register. 10 pcmcia_rdy_change 1'b0 this bit is set when card ready signal changes. it is cleared by a read. if this bit is set an interrupt will be raised if it is not masked in the pcmcia_cfg register. 15:11 reserved 6'h0 reserved 63:16 notimp 48?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 12: pcmcia control interface page 395 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 396 section 13: gpio document 1250_1125-um100-r section 13: gpio i ntroduction the part has a number of pins that are available for general use as inputs, outputs or interrupt inputs. these pins are controlled entirely by software. in addition, there are a number of pins allocated to other peripherals that may be used as general pins if the peripheral is not required. t he gpio p ins the gpio pins can be configured for use as either inputs or outputs, and can be set to raise an interrupt. a single gpio pin is shown in figure 82 . figure 82: single gpio pin diagram the gpio_direction register sets the direction of each pin individually, bits in it should be set to enable the output buffer. when used as outputs (shown in the bottom of the figure) the cpu sets and clears bits in the output latch by writing 1s to the gpio_pin_set or gpio_pin_clr registers, and the pin will change state. the output register retains its state even when the line is configured as an input, so if an "open collector" output is required the output register only needs to be set low once and the direction of the pin can be changed from output (to pull low) to input (to float). the input path is always active. an optional inverter is enabled by setting the corresponding bit in the gpio_input_invert register. the 100mhz reference clock is used to synchronize the signal to the internal logic and to provide filtering against glitches. by default the line has to change state for about 60ns before being recognized (a 60ns glitch filter), but the filter may be increased to provide a 1 ms glitch filter. the state of the gpio pin (after inversion and the glitch filtering) is readable from the gpio_read register. glitchfilter 60 ns or 1 ms s r gpio_input_invert[n] gpio_int_type[n=0,2,4,6,8,10,12,14] gpio_int [n] bit [n] set in write to gpio_clr_edge gpio_read [n] bit [n] set in write to gpio_pin_set bit [n] set in write to gpio_pin_clr gpio_direction[n] set and pin used for gpio pin rising edge detect clr 0 1 gpio_glitch[n] 0 - 60 ns filter 1 - 1ms filter gpio_int_type[n+1] gpio_int_type[n=0,2,4,6,8,10,12,14] or ~ gpio_int_type[n=1,3,5,7,9,11,13,15] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 13: gpio page 397 gpio lines can be enabled as interrupts in pairs. for each pair, both can have their interrupts disabled, both can be level interrupts, both can be edge sensitive interrupts or one can be level and the other an edge interrupt. this is selected in the gpio_int_type register. when a level interrupt is selected the input after inversion and glitch filtering is directly passed to the interrupt mapper in the scd (see section: ?the full interrupt mapper? on page 50 ) where it must be high to signal an interrupt. if the edge detector is enabled, the signal to the scd is asserted when a rising edge is detecte d on the output of the glitch filter, the signal is cleared when the corresponding bit is set in a write to the gpio_clr_edge register. a negative edge can be detected by inverting the input. masking of the gpio interrupt lines is also done in the interrupt mapper. the interrupt function is not affected by the direction of the line, if the gpio pin is set as an output then the interrupt will be raised whenever the output is set appropriately (after the glitch filtering delay). some of the gpio pins are used by the pcmcia controller and some to provide parity on the generic bus. these functions are set by reset time configuration resistors on the generic bus ad lines. when used for pcmcia operation the input inverters must be disabled by leaving gpio_input_invert bits [15:6] in their default state as zeros. the gpio signals are summarized in the table below. table 275: gpio pins and alternate uses gpio bit alternate name alternate use 1:0 s1:0_rstrobe synchronous serial output strobes. 5:2 io_adp[3:0] generic bus parity. 6 pc_ce1_l pcmcia card enable output. 7 pc_ce2_l pcmcia card enable output. 8 pc_reset pcmcia card reset output. 9 pc_ready pcmcia ready input. 10 pc_reg_l pcmcia regular/attribute select output. 11 pc_wp pcmcia write protected input. 12 pc_cd1_l pcmcia card detect input (the 1ms glitch filter is always used). 13 pc_cd2_l pcmcia card detect input (the 1ms glitch filter is always used). 14 pc_vs1_l pcmcia voltage sense input (the 60 ns glitch filter is always used). 15 pc_vs2_l pcmcia voltage sense input (the 60 ns glitch filter is always used). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 398 section 13: gpio document 1250_1125-um100-r gpio r egisters there are eight gpio registers. table 276: gpio edge clear register gpio_clr_edge - 00_1006_1a80 write only bits name default description 15:0 edge_clr 16'h0 writing a 1 in a bit position in this register will clear the corresponding edge detector. 63:16 notimp 48?bx not implemented. table 277: gpio interrupt type register gpio_int_type - 00_1006_1a88 bits name default description 1:0 int_type0 2'b0 the two bit fields set the interrupt type for each pair of pins. 00: disable both lines. the interrupts will never be raised. 01: both gpio pins are edge sensitive interrupts. 10: both gpio pins are level sensitive interrupts. 11: the even numbered pin is an edge sensitive interrupt the odd numbered pin is a level sensitive interrupt. 3:2 int_type2 2'b0 5:4 int_type4 2'b0 7:6 int_type6 2'b0 9:8 int_type8 2'b0 11:10 int_type10 2'b0 13:12 int_type12 2'b0 15:14 int_type14 2'b0 63:16 notimp 48?bx not implemented. table 278: gpio read register gpio_read - 00_1006_1aa0 read only bits name default description 15:0 gpio 16'h0 reads give value on each pin, after the optional inverter and glitch filtering. 63:16 notimp 48?bx not implemented. table 279: gpio input invert control register gpio_input_invert - 00_1006_1a90 bits name default description 15:0 invert 16'b0 each bit controls the input inverter for the corresponding gpio pin. if a bit is set then the value used internally and read in the gpio_read register will be the inverse of the value on the pin. 63:16 notimp 48'bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 13: gpio page 399 table 280: gpio glitch filter select register gpio_glitch - 00_1006_1a98 bits name default description 1:0 gpio_glitch 2'h0 when high the input from the pin has a 1ms glitch filter, when low a 60 ns glitch filter. 5:2 gpio_glitch 4'h0 when high the input from the pin has a 1ms glitch filter, when low a 60 ns glitch filter. if generic bus parity is enabled these bits are ignored. 15:6 gpio_glitch 10'h0 when high the input from the pin has a 1ms glitch filter, when low a 60 ns glitch filter. in pcmcia mode these bits are ignored. 63:16 notimp 48?bx not implemented. table 281: gpio direction register gpio_direction - 00_1006_1aa8 bits name default description 1:0 gpio_ddr 2'h0 high for output driven from the output latch, low for input. if the synchronous serial interface rstrobeout output is enabled this register is ignored and the pin will be an output. 5:2 gpio_ddr 4'h0 high for output, low for input. when generic bus parity is enabled these bits are ignored. 15:6 gpio_ddr 10'h0 high for output, low for input. when pcmcia is enabled these bits are ignored. 63:16 notimp 48?bx not implemented. table 282: gpio pin clear register gpio_pin_clr - 00_1006_1ab0 write only bits name default description 15:0 pin_clr 16'h0 writing a 1 to a bit position will clear that bit in the output latch. 63:16 notimp 48?bx not implemented. table 283: gpio pin set register gpio_pin_set - 00_1006_1ab8 write only bits name default description 15:0 pin_set 16'h0 writing a 1 to a bit position will set that bit in the output latch 63:16 notimp 48?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 400 section 13: gpio document 1250_1125-um100-r o ther p ins t hat c an b e u sed the part has many built in peripherals, and in any particular application it is possible that some of them are not used. pins on some of the peripherals can be used to provide additional software controlled input, output or interrupt lines. this section describes some of these. s erial p orts if a serial port is unused most of its pins can be reused. the port should be configured in asynchronous mode. all of the input pins (except for the data input pin) can be read through the duart_in_port register. the output handshake pins can be used by configuring them for software control. in an extreme case it would be possible to use the data out pin by enabling the transmitter and either letting the line idle (by sending nothing) to give a high output, or sending a break to give a low output. the following table summarizes the pins that can be directly used. see section: ?operation? on page 322 for how to configure the uart and control the i/o lines. pci if the pci bus is not used the pci interrupt lines can be used as active low level interrupt inputs, as can the serr and perr signals. if the pci is in device mode the p_intb_l, p_intc_l and p_intd_l lines can be used as active low level interrupt lines. mac s the mac management interface provides the only pins that can easily be used from an unused mac interface. the mdio line provides input and output, and the mdc line is output only. the geno pin from a mac is available as a general output unless the interface is in 16 bit bypass mode. the fifo mode of the mac may be used for bulk data dma transfers, but there is no easy way to use it for programmed i/o. pcmcia p ower c ontrol p ins the pcmcia power control pins are three dedicated outputs that are forced low when the part is reset. if pcmcia support is not required then these lines can be used as general outputs by setting the pcmcia power logic for software power control and writing the power control bits. this is described in section: ?using the power outputs? on page 392 . table 284: other pins that can be used as general inputs or outputs pin name direction channel a access (n=0) channel b access (n=1) sn_rts_tstrobe output op[0] op[1] sn_cout output op[2] op[3] sn_cts_tclkin input transition detect ip[0] ip[1] sn_cin_rclkin input transition detect ip[2] ip[3] sn_tin input ip[4] ip[5] sn_rin input ip[6] ip[7] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 13: gpio page 401 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 402 section 13: gpio document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 403 section 14: serial configuration interface i ntroduction there are two serial configuration interfaces based on the smbus. the interfaces provide hardware assistance for simple read and write of slave devices with the part as the bus master. the hardware assistance provides a subset of the smbus version 1.1 specification published by the smart battery system implementers forum . the bus clock is programmable, it should be set in the 10-100khz range for conformance operation, but can go higher. in particular many devices can use a 400khz clock. smb us o verview there are a large number of devices that can be configured using a two wire serial interface with one clock wire and one data wire. the interface to these devices is basically the same, but there are differences in timing and electrical specifications. the serial configuration interface is based on version 1.1 of the system management bus (smbus) standard from the smart battery system implementers forum (sbs-if), but has been generalized to support other devices. this interface only implements a subset, so is not fully compliant with the smbus 1.1 specification. this section provides a brief introduction to the interface, for full details see the smbus specification that may be found on the smbus web site at http://www.smbus.org and the related documents. devices on the serial configuration bus may be masters or slaves (or both). the interface is always a master. masters can issue commands, provide the clock and control the transfer. slaves respond to commands from masters and use the supplied clock. each slave has a unique 7 bit address (or a few addresses) that the master uses to select it. transactions always start with the master sending a byte containing the address of the slave and a single bit that indicates if the master is reading from the slave or writing to it. following this one or more bytes of data are transferred. the smbus adds a protocol layer above this basic transport. t ransport p rotocol devices connected to the serial configuration bus use open drain outputs on both the clock and data lines. pull- up resistors restore the lines high when no device is driving. the inputs should not be pulled above 3.3v. both the data (sda) and clock (scl) lines are high when idle. in normal operation sda will only change while scl is low. sda changing with scl high is used to signal control flags. figure 83 shows the three conditions for bit transfer on the smbus: start a start condition is used to indicate the beginning of a transaction. it consists of sda changing from high (idle) to low while scl remains high (idle). data bit a data bit is transferred by putting it on the sda line with the scl clock low and pulsing the clock high and then low with sda stable. data bytes are sent with the most significant bit first. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 404 section 14: serial configuration interface document 1250_1125-um100-r stop a stop condition signals the end of a transaction. it consists of sda making a transition from low to high (idle) while scl is high (idle). figure 83: smbus signaling start, data transfer and stop a master will initiate a transfer by sending a start condition. this causes all slaves to listen to the next byte which includes the 7 bit address and a single read/write bit. following this the master sets sda idle and pulses scl once more. if a slave matches the address it will acknowledge by holding sda low. bytes are then transferred in the direction marked by the read/write bit, with the receiver (slave during a write, master during a read) acknowledging after each. bytes continue to be transferred until the slave does not acknowledge a byte or the master decides all bytes have been transferred. the transaction is then ended by the master signalling a stop, which returns both lines to idle. there may be multiple masters on the bus. most of the ti me they will see the start and stop framing of other masters to avoid collision, however if two masters start at the same time they may collide. in this case the first time their sda signals differ the master that drives the line to zero wins arbitration and the other must back off. when forced to back off the interface will retry after it sees a stop condition, or if scl and sda are both high for 50 us (this is defined as an idle condition). the timing specification for slave devices tends to vary with frequency. to comply with both the standard timings at 100 khz and typical timings at 400 khz the interface produces a scl clock signal with a 9:7 ratio of time low:time high. the slave device is permitted to slow the clock by stretching the low period. if a slave has stretched the clock for 25 ms then an error has occurred and the master will abort the transfer. sda scl d7 d6 d5 d4 d3 d2 d1 d0 a/n start stop ack/nack from receiver byte of data transferred user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 405 t ransport p rotocol r eset a system reset during an smbus transaction can leave the bus in an unuseable state. the reset will cause the master to release the clock line and scl will therefore go high. but many slaves do not detect the system reset, and if a slave is being read it is not permitted to change the state of the data line while the clock is high. following a reset it is possible for a slave to be driving the sda low while scl is high. all masters will backoff from using the bus since it looks as though it is in use. a start or stop cannot be sent because the slave is forcing the sda low. the interface will attempt to clear this bad state. if sda is detected low when the interface is released from reset it will issue clock pulses on scl until sda goes high. in the absence of protocol errors, at most 9 clock pulses are needed to ensure that any slave that believes a read is in progress will complete transfer of a byte (of 0s) and see a nack, causing it to end the transaction. if sda goes high before the slave believes the transaction is finished the interface will stop providing clock pulses but the bus will be left in a state where a new master can initiate a new transaction. the start of the next transaction will ensure all slave state machines are resynchronized to the command stream. if a genuine transcation is in progress under the control of another master the part's attempt to clear state will at worst result in clock cycle stretching and should not interfere with the transaction. during the reset procedure accesses to the control registers are held off. this will at most last for the first 90us after reset so it is unlikely to be noticed in practice. smb us p rotocol the smbus protocol defines a number of transfer types between the host and peripherals. the interface implements all of these except for process call and block transfers. the latest revision of the smbus includes packet error code (pec) checking, this appends an 8-bit crc (using the polynomial x 8 +x 2 +x+1) at the end of the message. the crc is calculated across all bytes in the transfer (address, mode and data). the receiver can verify correctness of the crc and issues a not acknowledge if it is incorrect. the interface allows use of pec by optionally adding a byte at the end of a transfer, but the hardware will neither generate nor check the pec byte. software should calculate the correct value to be sent with writes and must load this into the smb_pec register before starting the transfer. if the crc check fails at the slave device it will nack the pec byte and an error will be reported in the smb_status register. when the interface receives pec it is always acting as the transaction master, so the hardware will always nack the byte and signal a stop to terminate the transfer. software should then check the smb_pec register and can retry the transfer if it detects an error. the supported smbus commands are listed in table 285 , along with the parameters they use. table 285: supported smbus transfer types transfer type (smb_tt) command (smb_cmd) 1st byte (smb_data[7:0]) 2nd byte (smb_data[15:8] description in the figures below s = start, p = stop, a = ack, a = nack, wr (write) = 0, rd (read) = 1 bits driven by the slave are shaded quick command (110) no no no send a single bit (in the r/w bit position) to the slave. s slave address data 17 111 a p bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 406 section 14: serial configuration interface document 1250_1125-um100-r if the device that is addressed is not an smbus device, then it will most likely use a different protocol. in this case a mapping will need to be done from the smbus commands to those that the device supports. the send byte and receive byte commands perform the fundamental transfers, but in many cases the other commands can be used (for example many memory devices can use the read word command to set the address pointer and read back two bytes). since it is not interpreted by the hardware the pec byte can be used as an additional byte in the transfer. send byte (000) yes no no send a single byte to the slave. receive byte (101) no no data read a single byte from the slave using a simple read with no associated command. write byte (001) yes data no send a command byte and a single data byte to the slave. read byte (011) yes data no send a command to the slave and read back a byte. write word (010) yes lsb msb send a command and two bytes to the slave. read word (100) yes lsb msb send a command to the slave and read two bytes. eeprom read (111) yes lsb msb send a command and one byte to the slave and read four bytes back. this matches a 32 bit read from a >16 kbit eeprom. table 285: supported smbus transfer types (cont.) transfer type (smb_tt) command (smb_cmd) 1st byte (smb_data[7:0]) 2nd byte (smb_data[15:8] description s slave address wr command code p 17 118 11 a a s slave address rd a p 17 118 11 a data byte s slave address wr command code data byte p 17 118 1811 a a a s slave address wr command code s slave address rd s slave address wr command code a p 17 118 1 7 111811 a a a data byte s slave address wr command code data byte low p 17 118 1 8 11 1 data byte high a a a a 8 s slave address wr command code s slave address rd a s slave address wr command code 17 118 1 7 11181 a p 811 . . . a a a data byte low data byte high s slave address wr command code data byte low 17 118 1 8 1 . . . s slave address rd a 17 118 1 data byte high a 1 a a a data byte low a ap 81 1 xtra byte high a 1 xtra byte low . . . 8 8 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 407 e xtended p rotocol the extended protocol mode of the interface supports a much wider range of devices by allowing transactions other than those specified in smbus. up to seven bytes can be written to a device, and up to seven bytes read. an extended mode transaction consists of a command/address being written to the device followed by either data being written to the device or a repeated start and data being read from the device. a write transaction consists of writing a command/address, with the format selected from table 286 , followed by write data, selected from table 287 . if pec is enabled then an additional byte from the smb_pec register will be sent before the stop. (the interface places no interpretation on the bytes, the names command/ address, data and pec just refer to conventional use of these bytes.) a read transaction consists of writing the command/address, as shown in table 286 , followed by a repeated start and reading data, as shown in table 288 . if pec is enabled then an additional byte will be read into the smb_pec register before the nack and stop. the co mmand/address may be null, in which case the start shown in table 288 will be a standard start not a repeated one. the extended mode is invoked by setting the extend bit in the smb_start register, this changes the interpretation of some of the other fields. thus smbus and extended transactions can be freely mixed. table 286: command/address options smb_start[12:11] address type operation 00 just read this is for reads that do not have an address phase. the start (and slave address) that is part of the read becomes a regular start rather than a repeated start. 01 slave address 10 byte address 11 16 bit address s slave address wr 17 11 a . . . s slave address wr command [7:0] 17 118 1 a a . . . s slave address wr command [7:0] command [15:8] 17 118 1 8 1 a a a . . . table 287: write data options smb_start [10:8] data format operation 000 1 byte 001 2 bytes 010 3 bytes 011 4 bytes data[7:0] 81 a . . . p 1 data[7:0] data [15:8] p 81811 a a . . . data[7:0] data [15:8] xtra [7:0] 818181 a a a . . . 1 p data[7:0] data [15:8] xtra [7:0] 818181 a a a . . . xtra [15:8] 81 a 1 p bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 408 section 14: serial configuration interface document 1250_1125-um100-r 100 no data 101 110 111 reserved reserved encodings. unpredictable operation. table 287: write data options (cont.) smb_start [10:8] data format operation 1 . . . p table 288: read data options smb_start [10:8] data format operation 000 1 byte 001 2 bytes 010 3 bytes 011 4 bytes 100 no data 101 5 bytes s slave address rd 17 118 1 data [7:0] a . . . p 1 a s slave address rd a 17 118 1 data [15:8] 1 data [7:0] a . . . 8 1 p a . . . s slave address rd a 17 118 1 data [15:8] a 1 data [7:0] a p 81 a 1 xtra [7:0] . . . 8 . . . s slave address rd a 17 118 1 data [15:8] a 1 data [7:0] a ap 81 1 xtra [15:8] a 1 xtra [7:0] . . . 8 8 s slave address rd 17 11 a . . . p 1 . . . s slave address rd a 17 118 1 command[7:0] a a 81 data [15:8] a 1 data [7:0] . . . 8 ap 81 1 xtra [15:8] a 1 xtra [7:0] 8 . . . user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 409 p rogramming m odel u sing smb us p rotocols a transfer is configured by setting data values in the smbus registers and writing the transfer type to the smb_start register. this starts the operation. if the remote device fails to acknowledge when expected to then the transfer is abandoned with an error. if the interface loses arbitration or detects over-long slave stretching then the transfer is aborted. the interface will retry an aborted transfer 15 times before abandoning it with an arbitration error. reading from a slave on the serial bus involves these steps: 1 wait until the busy bit in the smb_status register is clear. the interface will ignore accesses while the bit is set. 2 for a read byte (but not a receive byte) transfer specify the command to be sent by writing to the smb_cmd register. 3 specify the device address and the transfer type by writing to the smb_start register. this will cause the transfer to begin. the busy bit in the smb_status register will be set to a one as long as the transfer is in progress. 4 when the transaction finishes the busy bit will be cleared. this can either be detected by polling the smb_status or by enabling the smb_finish interrupt. the error bit indicates that an acknowledgement was not received from the slave device when the master attempted to start the transaction. 5 read the data from the smb_data register. if one byte was requested, only the lsb field will be valid. 6 if pec is enabled the smb_pec register should be read and checked. writing to a slave on the serial bus involves these steps: 1 wait until the busy bit in the smb_status register is clear. the interface will ignore accesses while the bit is set. 2 specify the command to be sent as the first byte by writing it in the smb_cmd register. 3 if data is being sent write it in the smb_data register. 4 if pec is being used the crc must be calculated by the software and written to the smb_pec register. 5 specify the device address and the transfer type by writing to the smb_start register. this will cause the transfer to begin. the busy bit in the smb_status register will be set to a one as long as the transfer is in progress. 110 6 bytes 111 reserved reserved encoding. unpredictable operation. table 288: read data options (cont.) smb_start [10:8] data format operation . . . s slave address rd a 17 118 1 command[15:8] a 1 command[7:0] a a 81 data [15:8] a 1 data [7:0] . . . 8 8 ap 81 1 xtra [15:8] a 1 xtra [7:0] 8 . . . bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 410 section 14: serial configuration interface document 1250_1125-um100-r 6 when the transaction finishes the busy bit will be cleared. this can either be detected by polling the smb_status register or by enabling the smb_finish interrupt. the error bit indicates that an acknowledgement was not received from the slave device at some point during the transaction. (it is important to check the data sheet for the slave device, some will always terminate a transaction by not sending an acknowledgement). a quick command can be sent with these steps: 1 wait until the busy bit in the smb_status register is clear. the interface will ignore accesses while the bit is set. 2 specify the device address, the command bit (which is sent as the r/w bit in a quick command) and the transfer type by writing to the smb_start register. this will cause the transfer to begin. the busy bit in the smb_status register will to be set to a one as long as the transfer is in progress. 3 when the transaction finishes the busy bit will be cleared. this can either be detected by polling the smb_status register or by enabling the smb_finish interrupt. the error bit indicates that an acknowledgement was not received from the slave device. an eeprom read is a write with a command and one data by te followed (without a stop) by a read of four data bytes (and optional pec). typically the command and data byte will contain the address to be read. the command sequence reflects this: 1 wait until the busy bit in the smb_status register is clear. the interface will ignore accesses while the bit is set. 2 specify the command (high address bits) to be sent as the first byte by writing it in the smb_cmd register. 3 specify the data (low address bits) to be sent by writing it in the smb_data register. 4 specify the device address (on some eeproms the low three bits of the device address provide an additional three address bits) and the transfer type by writing to the smb_start register. this will cause the transfer to begin. the busy bit in the smb_status register will to be set to a one as long as the transfer is in progress. 5 when the transaction finishes the busy bit will be cleared. this can either be detected by polling the smb_status register or by enabling the smb_finish interrupt. the error bit indicates that an acknowledgement was not received from the slave device when the master attempted to start the transaction or as the address was written. 6 read the data from the smb_data (from address and address+1) and the smb_xtra (from address+2 and address+3) registers. 7 most eeproms do not support pec. using standard parts if pec is enabled the smb_pec register will contain a fifth byte of data (from address+4). the smbus specification includes a process call command and block read and write commands for transferring up to 32 bytes of data. the interface does not support these operations. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 411 u sing e xtended p rotocols a transfer is configured by setting data values in the smbus registers and writing the transfer type with the extend bit set to the smb_start register. this starts the operation. if the remote device fails to acknowledge when expected, then the transfer is abandoned with an error. if the part loses arbitration or detects over-long slave stretching then the transfer is aborted. the in terface will retry an aborted transfer 15 times before abandoning it with an arbitration error. reading from a slave on the serial bus involves these steps: 1 wait until the busy bit in the smb_status register is clear. the interface will ignore accesses while the bit is set. 2 if the read is preceded by an address/command (other than just a slave address) write the smb_cmd register with the 8 or 16 bit data to be sent. 3 specify the device address and the transfer type by writing to the smb_start register. this will cause the transfer to begin. the busy bit in the smb_status register will be set to a one as long as the transfer is in progress. 4 when the transaction finishes the busy bit will be cleared. this can either be detected by polling the smb_status or by enabling the smb_finish interrupt. the error bit indicates that an acknowledgement was not received from the slave device when the master attempted to start the transaction. 5 read the data from the smb_cmd , smb_data and smb_xtra registers. 6 if pec is enabled the smb_pec register should be read. writing to a slave on the serial bus involves these steps: 1 wait until the busy bit in the smb_status register is clear. the interface will ignore accesses while the bit is set. 2 if an address/command is needed write 8 or 16 bits to the smb_cmd register. 3 write the data to the smb_data and smb_xtra registers. 4 if pec is enabled an extra data byte should be written to the smb_pec register. 5 specify the device address and the transfer type by writing to the smb_start register. this will cause the transfer to begin. the busy bit in the smb_status register will be set to a one as long as the transfer is in progress. the smbus interface is accessed through a number of registers in the i/o portion of the memory map. the two interfaces are identical, register names in this discussion should have _0 or _1 appended to indicate the interface. there are two interrupts generated from each interface. both interrupts are maskable through the control register. the smb_finish interrupt is generated when the interface completes an operation and the smb_busy status bit changes from one to zero, the interrupt is cleared by a read from the status register. the smb_error interrupt is generated when an error condition occurs, both the interrupt and status bit are cleared by writing a 1 to the error bit in the status register. prior to using the configuration interface the cloc k speed should be set. this is derived from the 100 mhz reference clock as configured in the smb_freq register. the two standard frequencies are 100 khz and 400 khz, but a much wider range can be programmed. since the setup and hold time parameters vary betweeen different slave devices it may be necessary to run the interface slightly slow to ensure reliable operation. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 412 section 14: serial configuration interface document 1250_1125-um100-r d irect a ccess the interface allows the hardware assist to be disabled giving direct ("bit-banged") access to the sda and scl lines. the cpu executes the whole protocol in software. this is useful for connecting to devices that deviate from the standard. direct access is enabled through the smb_control register. two bits in the smb_control register are used to set the sda and scl lines to drive low or go high impedance, and two bits in the smb_status register reflect the current state of the lines. the output from the smb bi t clock is provided in the status register since it may be useful for timing transfers. b ooting u sing an smb us eeprom the part can be configured to boot using an eeprom connected to smbus interface 0. when configured this way accesses to the generic bus chip select 0 space are converted into smbus accesses using either the eeprom read or read word protocols. since there is a large protocol overhead and the smbus will be running at the default 100 khz, accessing the bootstrap code in this way is slow. typically, a small primary bootstrap program would be run from the eeprom (which can also store the ethernet ids for the part), this would do sufficient initialization to load the system code from a master device. the boot_type is configured using resistors on the generic bus pins io_ad[18:17] as described in section: ?reset? on page 26 . the value on these is readable in the system configuration register ( table15onpage43 ). while bit 18 is set in this register the smbus 0 interface will only be used for servicing accesses to generic bus chip select 0. while the smbus interface is being used for booting any access to its control registers have unpredictable results. once booting is complete software can clear bit 18 in the system configuration register to allow normal smbus use. this will return the chip select 0 space to using the generic bus to service accesses. following smbus use software must set the chip select 0 timing parameters (even if it is setting the default values) before any access is made to the chip select 0 space or the results will be unpredictable. when the system is reset by any method that causes the configuration bits to be sampled (see table 8 on page 27 ), bit 18 in the system configuration register will be set again, and the smbus will be used for booting. if the watchdog timer is set to reset only one (or both) of the cpus then the scd will not be reset and the smbus will not be reselected. in this configuration either the smbus interface must be dedicated to be used by the generic chip select 0, or a rom must be put on the generic bus to service the watchdog resets. the boot mode works with eeproms that have the standard interface and use smbus address 1010xxx. the low bits from address that the cpu issues to the generic bus (that would normally be put out on io_ad) is sent to the smbus interface, which runs an addressed cycle to the eeprom and returns 32 bits of data that would normally be placed in the smb_data and smb_xtra registers. two protocols are in use for these eeproms: eeproms <= 16k bit if the boot_type is configured as 2?b10 the part will boot from a small eeprom (up to 2k bytes) accessed using a modified read word protocol that fetches four bytes: the upper 4 bits of the smbus device address are set to 4?b1010. the low three bits of the smbus device address are set to bits [10:8] of the address being accessed. the command byte is set to bits [7:0] of the address being accessed. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 413 eeproms > 16k bit (boot type = 2?b11) if the boot_type is configured as 2?b11 the part will boot from a large eeprom (bigger than 2k bytes) accessed using the eeprom read protocol. the upper 4 bits of the smbus device address are set to 4?b1010. the low three bits of the smbus device address are set to bits [18:16] of the address being accessed. the command byte is set to bits [15:8] of the address being accessed. the data byte is set to bits [7:0] of the address being accessed. the data that returns from the smbus interface is aligned and assembled to satisfy the request by the generic bus logic as if it had been returned by a 32 bit wide rom attached to the generic bus. note that if the smbus transaction fails (for example the interface loses arbitration 15 times) then there is no way to recover and the boot process will hang (in this situation the cpu graduation timer will eventually trigger a machine check exception, but since the exception vector is also di rected to the boot rom it will also be unable to make progress). s witching from smb us m ode care must be taken when switching out of the smbbus boot mode. there must be no accesses in progress to the chip select 0 region when the switch is made or the system will behave in undefined ways (for example a response could be lost). instruction fetches are a particular concern and careful location of instructions is required to avoid them causing a problem. two cases will be described as examples, in both cases the system is initially running from smbus boot space in the generic chip select 0 region. (these examples are selected to provide simple illustration of the problem and are not representative of real systems.) the first case is when the smbus boot bit is cleared and the system continues running from a device in the chip select 0 generic bus region. this could be done when the smbus code is used to configure the region with a different timing from the default. // fetching from cs0 region from smbus // t1 points to generic cs0 config registers // t3 points to scd registers addr: // this is on a cache block boundary sh t5, io_ext_time_cfg0(t1)//set timing registers sh t6, io_ext_time_cfg1(t1) sync sync addr+16: sh t4, io_ext_cfg(t1)//set config sd t7, system_cfg(t3)//remove smbus boot sync sync addr+32: // fetched from cs0 on the generic bus bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 414 section 14: serial configuration interface document 1250_1125-um100-r in this example the chip select 0 timing regist ers are configured in one instruction bundle. the sync instructions serve to pad out the bundle and prevent the next four instructions being fetched until the stores have been issued (the sb-1 will only issue an uncacheable instruction fetch when the previous instructions have graduated). the second group of four instructions write to the configuration to complete the setup and to the system_cfg register to disable smbus booting. again the sync instructions are used to ensure these writes have issued. this is sufficient to ensure the mode has changed and the next instruction fetch will be serviced from the generic bus. the second example is switching to the chip select 1 region at the same address. this can be done to move to a generic bus device while leaving the smbus mode enabled to allow a soft reset to revert back to smbus mode. again care must be taken during the switch-over. here the timing is set for the chip select 1 region in the first instruction bundle. the second group sets the size of the chip select 1 region, changes the base of chip select 0 to move it out of the way and configures the base of chip select 1 to 00_1fc0_0000 . it is important that the second group of instructions are together since they change the target of the next instruction fetch. again the sync instruction is used to ensure that the stores have completed before the cpu will issue the next instruction fetch. if the chip select region 1 were located at a different address then there would be no need to move the chip select region 0 base address. in this case the two cs1 stores (of t5 and t7) would be the first two instructions in the bundle, the third instruction would be the branch to the new address range and the sync would be in the branch delay slot. having the branch third and the sync in the delay slot will ensure that the stores are completed (due to the sync and the sb-1 not fetching more instructions until the current ones graduate) and the next instruction fetch comes from the chip select 1 space (because of the jump and the fact that its delay slot is satisfied from the current instruction bundle). // fetching from cs0 region from smbus // t0 points to generic cs0 config registers // t1 points to generic cs1 config registers // t2-7 have configuration values addr: // this is on a cache block boundary sh t2, io_ext_time_cfg0(t1)//set cs1 timing registers sh t3, io_ext_time_cfg1(t1) sh t4, io_ext_cfg(t1)//set cs1 config sync addr+16: sh t5, io_ext_size(t1)//set cs1 size (to 0x3f = 4mb) sh t6, io_ext_base(t0)//move cs0 base (to 00_2000_000) sh t7, io_ext_base(t1)//set cs1 base (to 00_1fc0_0000) sync addr+32: // fetched from cs1 on the generic bus user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 415 smb us r egisters the smbus registers are mapped into the internal i/o section of the memory space. they all occupy a 64 bit wide slot, although in most cases only one or two bytes are implemented. when a register is written its entire contents must be written, writes that are smaller than the implemented width will result in the register value becoming unpredictable. table 289: smbus clock frequency registers smb_freq_0 - 00_1006_0010 smb_freq_1 - 00_1006_0018 bits name default description 12:0 smb_freq_div 13'h7d the 100 mhz sys_clock is divided by this x 8 to determine the frequency of the serial clock. the default value is for 100 khz. the minimum smbus clock is 10 khz which is generated using a value of 1250. for 400 khz the value for this field is 31. 63:13 notimp 51?bx not implemented. table 290: smbus command registers smb_cmd_0 - 00_1006_0030 smb_cmd_1 - 00_1006_0038 read returns value from previous smbus read command. write sets value for next smbus write command. bits name default description 7:0 smb_cmd 8'h0 write : low byte of command to be sent following address. read : first byte received in type 5 or 6 extended mode read. 15:8 smb_cmdh 8'h0 write : high byte of command to send in extended mode. read : 2nd byte received in type 6 extended mode read. 63:15 notimp 56'bx not implemented. table 291: smbus control registers smb_control_0 - 00_1006_0060 smb_control_1 - 00_1006_0068 bits name default description 0 smb_mk 1'b0 when high, enables interrupt if error is high. 1 smb_finish_en 1'b0 when high, an interrupt will be generated when busy transitions from high to low. the interrupt is cleared by reading the smb_status register. 3:2 reserved 6'h0 reserved 4 smb_data_out 1'b0 driven to data pin in direct mode if smb_data_dir is set. 5 smb_data_dir 1'b0 data direction in direct mode, set for output clear to turn driver off. 6 smb_clk_out 1'b0 driven to clock pin in direct mode 7 smb_direct 1'b0 set to enable direct control of clock and data lines (from bits 6:4). 63:8 notimp 56?bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 416 section 14: serial configuration interface document 1250_1125-um100-r table 292: smbus status registers smb_status_0 - 00_1006_0020 smb_status_1 - 00_1006_0028 read clears finish interrupt bits name default description 0 smb_busy 1'b0 when high, indicates the serial interface is busy; when low, it is not busy. 1 smb_error 1'b0 when high, indicates an error has occurred. if the smb_mk bit in the smb_control register has a value of 1'b1, an interrupt will be generated. the interrupt and this status bit are cleared by writing this bit with a 1. 2 error_type 1'h0 when bit 1 is high this bit indicates the error that occurred. this bit is cleared if an expected acknowledgement is not seen and set if the transfer has failed after 15 retries. 5 smb_scl_in 1?bx reserved. will be used to provide value on scl pin in later revisions of the part. 4:3 reserved 2'b0 reserved 6 smb_ref 1'b0 in direct mode (smb_direct set in the control register) this bit shows the output of the serial clock generator (that would be driven to the clock pin in normal mode). software may use this as a reference clock. if direct mode is not enabled this bit is zero. 7 smb_data_in 1'b0 in direct mode (smb_direct set in the control register) this bit shows the value on the data pin, otherwise it is zero. 63:8 notimp 56?bx not implemented. table 293: smbus data registers smb_data_0 - 00_1006_0050 smb_data_1 - 00_1006_0058 read returns value from previous smbus read command. write sets value for next smbus write command. bits name default description 7:0 smb_lb 8'h0 least significant data byte that was read ( or will be written) across the serial bus. 15:8 smb_mb 8'h0 most significant data byte that was read (or will be written) across the serial bus. 63:16 notimp 48?bx not implemented. table 294: smbus extra data registers smb_xtra_0 - 00_1006_0000 smb_xtra_1 - 00_1006_0008 read returns value from previous smbus read command. write sets value for next smbus write command. bits name default description 7:0 smb_lb 8'h0 third data byte that was read in an eeprom read transfer. 15:8 smb_mb 8'h0 fourth data byte that was read in an eeprom read transfer. 63:16 notimp 48?bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 417 table 295: smbus packet error check registers smb_pec_0 - 00_1006_0070 smb_pec_1 - 00_1006_0078 read returns value from previous smbus read command. write sets value for next smbus write command. bits name default description 7:0 pec 8?h0 this register holds the pec information that is sent or received for a command that has the smb_pec bit set. the hardware does not generate or check the crc, software must do that. 63:8 notimp 56?bx not implemented. table 296: smbus start and command registers smbus mode smb_start_0 - 00_1006_0040 smb_start_1 - 00_1006_0048 bits name default description 6:0 smb_addr 7'h0 the serial interface address. these 7 bits are used to form the address byte that is sent across the serial interface. 7 smb_qdata 1'b0 bit of data to send as r/w bit in a quick command. ignored, write as zero for all other commands. 10:8 smb_tt 3'h0 value transfer type 000 1 byte write (address, command). 001 2 byte write (address, command, write least significant field of smb_data). 010 3 byte write (address, command, write both fields of smb_data). 011 command and 1 byte read (address, command, address, read byte into lb field of smb_data). 100 command and 2 byte read (address, command, address, read byte into lb field of smb_data, read byte into hb field of smb_data). 101 1 byte read (address, read byte into lb field of smb_data). 110 quick command (address with one bit of data). 111 eeprom read. reads 32 bits into smb_data and smb_xtra from a standard eeprom >16 kbit that needs 2 address bytes. 13:11 reserved 3'h0 reserved, set to zero 14 extend 1'b0 this bit should be set to zero for smbus protocol mode. 15 smb_pec 1'b0 set to modify the transfer type to use packet error checking as defined in the smbus 1.1 specification. zero for regular operation. 63:16 notimp 48'bx not implemented. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 418 section 14: serial configuration interface document 1250_1125-um100-r table 297: smbus start and command registers extended mode smb_start_0 - 00_1006_0040 smb_start_1 - 00_1006_0048 bits name default description 6:0 smb_addr 7'h0 the serial interface address. these 7 bits are used to form the address byte that is sent across the serial interface. 7 smb_qdata 1'b0 bit of data to send as r/w bit in a quick command. ignored, write as zero for all other commands. 10:8 smb_datafmt 3'h0 data format value data transfer 000 data[7:0]. 001 data[7:0], data[15:8] 010 data[7:0], data[15:8], xtra[7:0] 011 data[7:0], data[15:8], xtra[7:0], xtra[15:8] 100 no data. 101 only valid for read transactions cmd[7:0], data[7:0], data[15:8], xtra[7:0],xtra[15:8] 110 only valid for read transactions cmd[7:0], cmd[15:8], data[7:0], data[15:8], xtra[7:0], xtra[15:8] 111 reserved 12:11 smb_afmt 2'h0 address/command format value address/command transfer 00 only valid for read transactions: no address. 01 slave address only 10 slave address then cmd[7:0] 11 slave address then cmd[7:0], cmd[15:0] 13 smb_dir 1'b0 set to 0 for a write transaction, 1 for a read transaction. 14 extend 1'b1 this bit should be set to one for extended protocol mode. 15 smb_pec 1'b0 set to modify the transfer type to use packet error checking as defined in the smbus 1.1 specification. zero for regular operation. 63:16 notimp 48'bx not implemented. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 14: serial configuration interface page 419 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 420 section 14: serial configuration interface document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 421 section 15: jtag and debug i ntroduction the part includes extensive debugging and performance monitoring features. these can be accessed by the cpu(s) or through the jtag port. the jtag interface supports the required subset of mips ejtag 2.5 and additions to allow both processors to be debugged. the debug and bus trace unit in the scd can also be controlled through the jtag port. a jtag probe may be connected to the part for accessing both the boundary scan and debug functions. there is a standard connector for the mips ejtag interface. the application note?bcm1250 ejtag connector? #00- 117 from corelis inc. (www.corelis.com) includes a recommendation for the connector and terminations for the bcm1250 and BCM1125/h. tap c ontroller the sb1250 implements a ieee 1149.1 compliant test access port (tap) controller. the tms pin is used to control the tap state machine. if trst_l is asserted then the tap controller state machine enters the test- logic-reset state. figure 84 on page 422 shows the state machine used by the jtag interface. this is the standard jtag state machine. trst_l can be used to reset the state machine to the test-logic-reset state, which will also be entered if tms is asserted for five tck rising edges. the state machine advances each tck rising edge as directed by the tms level. the states are as defined in the jtag specification. the ir scan branch is used to scan instructions into the instruction register described in section: ?instruction register? on page 423 . the dr branch scans bits into and out of whatever data scan chain has been selected by an instruction. when trst_l is asserted or the tap enters the test-logic-reset state, the instruction register is loaded with the idcode instruction, any ejtagboot indication is removed and the ejtag control register is cleared. the coldres_l input is also used to reset the tap, this ensures that the scan chains and boundary scan drivers remain in a safe state as the power comes up. a side effect is that the tap is held in reset and none of the jtag machinery can be used while coldres_l is asserted. if testing is to be done using the jtag interface with the bcm1250 held in reset then reset_l should be used to keep the system in reset while allowing the jtag port to be active. the standard ejtag connector allows the probe to control reset_l. table 298: jtag signals jtag pin description tdi test data in. data is shifted serially in to the part through this input. tdo test data out. data is shifted serially out of the part through this output. tms test mode select. tap state machine control signal. the value captured on the rising edge of tck determines the state transition. tck test clock. the jtag interface can be clocked at up to 10 mhz. trst_l test reset. asserting this signal forces the tap state machine in to the test-logic-reset state. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 422 section 15: jtag and debug document 1250_1125-um100-r figure 84: jtag tap state machine test-logic-reset run-test-idle select-dr-scan select-ir-scan capture-dr capture-ir shift-dr exit1-dr pause-dr exit2-dr update-dr shift-ir exit1-ir pause-ir exit2-ir update-ir 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 10 1 0 1 0 1 0 0 1 1 0 0 1 10 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 423 i nstruction r egister the tap implements a 6 bit instruction register. the instructions are shown in table 299 . the required bypass, sample/preload, and extest instructions are implemented, along with the optional idcode, intest and clamp instructions. 25 additional bcm1250 specific instructions have been implemented. the instruction register is scanned in and out lsb first. the value scanned out of the instruction register has a 1 in the lsb and zeros in all other bits. table 299: jtag instructions ir value instruction function 0x00 extest selects the boundary scan register for extest. this is used to drive the external pins for testing board connectivity. 0x01 idcode selects chip identification data register. 0x02 reserved 0x03 impcode selects the implementation code register. 0x04-0x07 reserved 0x08 address selects the ejtag address register. 0x09 data selects the ejtag data register. 0x0a control selects the ejtag control register. 0x0b ejtagall selects the ejtag address, data and control registers. 0x0c ejtagboot force the cpus to boot in debug mode. 0x0d normalboot force the cpus to boot in the normal mode. 0x0e-0x1f ejtag reserved reserved for ejtag. 0x20 sysctrl selects system control and status register. 0x21 trace selects trace register for scan out. 0x22 perf selects performance counters for scan out. 0x23 tracectrl selects the trace control registers for scan out/in. 0x24 waferid selects the wafer id for scan out. 0x25 processmon selects the ring oscillator register for scan in/out. 0x26 cpu0osc broadcom use only. selects cpu0 observability chain. 0x27 cpu0dsc broadcom use only. selects cpu0 debug chain. 0x28 cpu0tsc broadcom use only. selects cpu0 test chain. 0x29 reserved 0x2a cpu1osc broadcom use only. selects cpu1 observability chain. 0x2b cpu1dsc broadcom use only. selects cpu1 debug chain. 0x2c cpu1tsc broadcom use only. selects cpu1 test chain. 0x2d reserved 0x2e scaniob0 broadcom use only. selects iob0 chain. 0x2f reserved 0x30 scaniob1 broadcom use only. selects iob1 chain. 0x31 reserved 0x32 scanl2c broadcom use only. selects l2c chain. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 424 section 15: jtag and debug document 1250_1125-um100-r bypass instruction the required bypass instruction allows the processor to remain in a functional mode and selects the bypass register to be connected between tdi and tdo. the bypass instruction allows serial data to be transferred through the processor from tdi to tdo without affecting its operation. the bit code of this instruction is defined to be all ones by the ieee 1149.1 standard. all unu sed instructions default to the bypass instruction. idcode instruction the idcode instruction selects the device identification (id) register to be connected between tdi and tdo. the device id register is a 32 bit shift register containing the 11 bit manufacture id (11?h150), the 16 bit part- number (this matches the part number in the system_revision register) and the 4 bit version number. the idcode register is scanned out lsb first and is shown in table 300 . the version number is 4?h1 for prototype bcm1250, 4?h2-4?h8 or 4?hb for initial production bcm1250 and 4?h9 for later production bcm1250 (stepping c0). the version number is 4?h1 for initial production BCM1125/h. waferid instruction the waferid instruction selects the waferid register to be connected between tdi and tdo. the waferid register is a 32 bit shift register containing a manufacturing lot code number. the register is scanned out lsb 0x33 reserved 0x34 scanmc broadcom use only. selects mc chain. 0x35 reserved 0x36 scanscd broadcom use only. selects scd scan chain. 0x37 reserved 0x38 scanall broadcom use only. selects all agent scan chains in series. 0x39 reserved 0x3a bsrmode keep boundary scan register active even if other jtag commands used. 0x3b tracecurcnt selects the current trace event counts for scan out. 0x3c clamp selects the bsr onto the outputs and selects the bypass register between tdo and tdi. 0x3d sample/ preload selects the boundary scan register. cause a snapshot to be taken of the state of the pins on the rising edge of tclk next time the state machine is in the capture-dr state. this is as required by the jtag standard. 0x3e intest sets up boundary scan for intest mode. this selects all of the inputs of the chip for control by jtag. 0x3f bypass bypass mode. select the bypass register between tdi and tdo, as required by the jtag standard. table 299: jtag instructions (cont.) ir value instruction function table 300: jtag device id register 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 jtag version number jtag part number jtag manufacturer 1 vvvvpppppppppppppppp001010100001 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 425 first and is shown in table 301 . this register can also be read in the top bits of the system_revision register (see table 14 on page 43 ). impcode instruction this instruction selects the implementation register for output, which is always 32 bits. the impcode for the bcm1250 and BCM1125/h is 32?h21404001 indicating ejtag 2.5, r4k style cp0, dint supported, asid size is 8 bits, no mips16 support, no ejtag dma, mips64 support. this code is defined by revision 2.5 of the mips ejtag spec. (older versions of the parts incorrectly report 32?h20814001.) address instruction this instruction is used to cause the address register to be connected between tdi and tdo. the ejtag probe shifts 77 bits through the tdi pin into the address register and shifts out the captured address via the tdo pin. the address register is described in section: ?address register? on page 438 . data instruction this instruction is used to cause the data register to be connected between tdi and tdo. the ejtag probe shifts 277 bits of data through the tdi pin into the data register as the captured data is shifted out via the tdo pin. the data register is described in section: ?data register? on page 438 . control instruction this instruction is used to select the ejtag control register to be connected between tdi and tdo. the ejtag probe shifts 12 bits of data into the ejtag cont rol register through the tdi pin, and shifts out the current value via tdo. the control register is described in section: ?ejtag control register? on page 439 . see the description of probe access in section: ?probe accesses to the zbbus? on page 437 . ejtagall instruction this instruction is used to select the concatenation of the address register, the data register, and the ejtag control register between tdi and tdo. the total chain is 366 bits.it can be used to accelerate scanning out of requests, since there is no need for instructions to be used to switch between the scan chains. ejtagboot instruction when the ejtagboot instruction is given and the update-ir state is left, the prtrap0 and prtrap1 bits are set in the ejtag control register to assert the dbboot signal to both cpus. the proben bit is set to allow cpu accesses to the jtag space. table 301: jtag wafer id register 3 1 3 0 2 9 2 8 2 7 2 6 2 5 2 4 2 3 2 2 2 1 2 0 1 9 1 8 1 7 1 6 1 5 1 4 1 3 1 2 1 1 1 09876543210 lot (swap bits 26-27, 20-21, 18-19) wafer broadcom use information bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 426 section 15: jtag and debug document 1250_1125-um100-r the dbboot signal will force the cpu to use the alternate debug vector when it enters debug mode. when the cpus are next reset, they will sample their dbboot signals and if it is asserted they will enter debug mode and start execution from the alternative debug vector (physical 00_1000_0480 ). the cpus will therefore enter debug mode and execute code from the jtag probe, without fetching or executing any instructions from the normal boot vector. this can be used to download code into a system which has no code in rom. the ejtagboot indication is effective until the normalboot instruction is given, trst_l asserted or a rising edge of tck occurs when tap controller is in the test-logic-reset state. the prtrap0 and prtrap1 bits may be cleared by scanning in to the ejtag control register and will read back as zeros, but this is not sufficient to clear the ejtagboot state. the bypass register is selected when the ejtagboot instruction is given. normalboot instruction when the normalboot instruction is given and update-ir state is left, then the dbboot signal is deasserted and the prtrap0, prtrap1 and proben bits in the ejtag control register are set to 0. since dbboot is deasserted the cpus will start at the standar d reset vector the next time they are reset. the bypass register is selected when the normalboot instruction is given. scan instructions (0x26 - 0x38) when these instructions are given the corresponding scan chain is selected. when the scanall instruction is given then all of the scan chains are selected in series in order tdi to mc to scd to l2c to iob1 to iob0 to cpu1 to cpu0 to tdo. these scan chains are for broadcom use only. scanning inappropriate values in to the chains can put the bcm1250 in an undefined state that requires both a system and a jtag reset to clear. sysctrl instruction the system control and status register is used to control the part for testing and debug purposes. this register is defined by table 15 on page 43 . the system control scanchain, summarized in table 15 , includes this register and additional control bits. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 427 table 302: system control scan chain system_cfg - 00_1002_0008 bits name default description 0 reserved ext configuration bit for io_ad[0]. 1 reserved ext configuration bit for io_ad[1]. indicates source for io_clk100. this must not be changed while the bcm1250 is operating. 2 ldt_minrstcnt ext configuration bit for io_ad[2]. broadcom use only. this must be zero for normal operation. 3 ldt_bypass_pll ext configuration bit for io_ad[3]. broadcom use only. this must be zero for normal operation. 4 pci_test ext configuration bit for io_ad[4]. broadcom use only. this must be zero for normal operation. 5 iob0_div ext configuration bit for io_ad[5] that controls the clock divider for i/o bridge 0. 0: iob0 runs at cpu clock/4, for use with fast cpu clocks. 1: iob0 runs at cpu clock/3, for use with slow cpu clocks. 6 iob1_div ext configuration bit for io_ad[6] that controls the clock divider for i/o bridge 1. 0: iob1 runs at cpu clock/3, for use with fast cpu clocks. 1: iob1 runs at cpu clock/2, for use with slow cpu clocks. 11:7 pll_div ext configuration bits for io_ad[11:7] that select the pll divide ratio. these bits must not be changed while the bcm1250 is operating. 12 ser0_enable ext configuration bit for io_ad[12]. 0: serial interface 0 is in asynchronous (uart) mode. 1: serial interface 0 is in synchronous mode. 13 ser0_rstb_en ext configuration bit for io_ad[13] that allocates gpio[0] pin to the synchronous serial interface. 14 ser1_enable ext configuration bit for io_ad[14]. 0: serial interface 1 is in asynchronous (uart) mode. 1: serial interface 1 is in synchronous mode. 15 ser1_rstb_en ext configuration bit for io_ad[15] that allocates gpio[1] pin to the synchronous serial interface. 16 pcmcia_enable ext configuration bit for io_ad[16] that configures the pcmcia mode. 18:17 boot_mode ext configuration bit for io_ad[18:17] that configures the boot mode. 00: 32 bit generic bus rom (multiplexed). 01: 8 bit generic bus rom (non-multiplexed). 10: smbus eeprom <= 16 kbit (read word protocol). 11: smbus eeprom > 16kbit (eeprom read word protocol). 19 pci_host ext configuration bit for io_ad[19], that configures the pci interface to be host or device mode. 20 pci_arbiter ext configuration bit for io_ad[20], that configures the pci interface to use an internal or external arbiter. (if the pci is set in device mode the resistor must be set for an external arbiter) 21 southonldt ext configuration bit for io_ad[21], that configures the southbridge to be on the hypertransport fabric or pci bus. 22 big_endian ext configuration bit for io_ad[22], that configures the system to be big or little endian. 23 genclk_en ext configuration bit for io_ad[23], that enables output of the generic bus clock on io_clk100. if this bit is zero then the io_clk100 will be held in a high impedance state. 24 ldt_test_en ext configuration bit for io_ad[24]. broadcom use only. this must be zero for normal operation. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 428 section 15: jtag and debug document 1250_1125-um100-r 25 gen_parity_en ext configuration bit for io_ad[25] that configured the generic bus parity. 31:26 config ext configuration bit for io_ad[31:26]. these configuration bits are available for interpretation by software. 32 clkstop 1'b0 writable via jtag only. broadcom use only. takes effect on updatedr. 33 clkstep 1'b0 writable via jtag only. broadcom use only. 41:34 clkcount 8'b0 writable via jtag only. broadcom use only. 42 pllbypass 1'b0 writable via jtag only. broadcom use only. 44:43 pll_iref 2'b0 writable via jtag only. broadcom use only. 46:45 pll_vco 2'b0 writable via jtag only. broadcom use only. 48:47 pll_vreg 2'b0 writable via jtag only. broadcom use only. 49 mem_reset 1'b0 writable via jtag only. when set the memory controller is held in reset. 50 l2c_reset 1'b0 writable via jtag only. when set the level 2 cache is held in reset. 51 io_reset_0 1'b0 writable via jtag only. when set the i/o bridge to the pci and hypertransport fabric is held in reset. 52 io_reset_1 1'b0 writable via jtag only. when set the i/o bridge to the slow speed devices and generic bus is held in reset. 53 scd_reset 1'b0 writable via jtag only. when set the scd is held in reset. 54 cpu_reset_0 1'b0 when set cpu 0 will be held in reset. 55 cpu_reset_1 1'b1 when set cpu 1 will be held in reset. this bit is set on a bcm1250 reset, causing the processor to remain in reset until released under software control. 56 unicpu0 1'b0 set to indicate uniprocessor using physical processor 0. (this bit will always be set on the BCM1125/h.) 57 unicpu1 1'b0 set to indicate uniprocessor using physical processor 1. 58 sb_softres 1'b0 when a write changes this bit from a 0 to a 1 a soft reset will be performed. this will reset of whole chip except for this register. note that once it is set the bit must be cleared before writing a 1 will again cause a soft reset. 59 ext_reset 1'b0 when set the resetout_l pin will be asserted. 60 system_reset 1'b0 when written with a 1 a full system reset will be performed (thus setting this bit back to zero). 61 misr_mode 1?b0 broadcom use only. set misr mode (1=misr 0=capture). 62 scd_misr_reset 1?b0 broadcom use only. reset scd misrs on 0->1 transition. 63 reserved 1?b0 reserved 95:64 stp_cnt 32?b0 broadcom use only. stop counter set to zero for normal operation. 96 pllstop 1?b0 broadcom use only. set to zero for normal operation. 97 stop_stre 1?b0 broadcom use only. set to zero for normal operation. 98 start_trc 1?b0 broadcom use only. set for trace, clear for reset. 99 stopping 1?b0 broadcom use only. read only. 100 ss_done 1?b0 broadcom use only. read only. 101 zbser_ard 1?b0 broadcom use only. serialize a-r-d. set to zero for normal operation. 102 zbser_ar 1?b0 broadcom use only. serialize a-r. set to zero for normal operation. table 302: system control scan chain (cont.) system_cfg - 00_1002_0008 bits name default description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 429 on the bcm1250 bits 104:0 of this register are selected in between tdi and tdo, on the BCM1125/h there are two additional broadcom use only bits so bits 106:0 are selected. the scan order is from lsb to msb. the configuration bits may be written by the jtag probe while the part is held in reset using reset_l provided the cold reset delay (tcr) described in the hardware data sheet has elapsed since coldres_l was released. most of the other bits in this scanchain are for broadcom use only, incorrect settings will cause the part to behave in undefined ways and could require a full cold reset to restore deterministic behavior. the cpu uniprocessor bits (in the resets field) are normally set by only on uniprocessor parts. however if one of these bits is set in the control register and then the broadcom-soft-reset bit is set, following the reset the bcm1250 will behave as a uniprocessor. this can be used to disable one of the processors, it will not be clocked and will enter a low power state. broadcom soft reset occurs only when a 1 is scanned into this register, and the tap controller enters the update-dr state. this reset is just like a normal reset except that the contents of the system control register are not reset. this allows testing of various modes. trace instruction when the trace instruction is set, the trace_read register is selected between tdi and tdo. this is a read only register. it is scanned out lsb first. the trace buffer should be frozen and the startread bit set prior to reading out. this is a 64 bit register, and gets the next 64 bits of trace data every time the capture-dr state is entered. it performs just as if the data had been read out using address 00_1002_0a08 . following a capture the first scan of the register returns unpredictable data and the next will return the first valid bits. after the entire contents of the trace buffer have been read, it will return all zeros. perf instruction the perf instruction selects the performance registers for scan in and out. note that the value scanned in will overwrite the counters. the performance chain is scanned out lsb first and is made up of the performance registers as shown in table 303 . 103:104 str_mode 2?b0 broadcom use only, sets stretch mode for pll. set to zero for normal operation. table 302: system control scan chain (cont.) system_cfg - 00_1002_0008 bits name default description table 303: performance counter scan chain bits register description 33:0 perf_cnt_cfg[33:0] performance counter configuration (see table 31 on page 61 ). 74:34 perf_cnt_0[40:0] performance counters (see table32onpage62 ). 115:75 perf_cnt_1[40:0] 156:116 perf_cnt_2[40:0] 197:157 perf_cnt_3[40:0] bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 430 section 15: jtag and debug document 1250_1125-um100-r tracectrl and tracecurcnt instructions the trace control registers are selected for both scan in and out using the tracectrl instruction. the registers are connected between tdi and tdo and are scanned out lsb first. the registers are scanned out in the order shown in table 304 , starting with trace_event_0[0] and ending with trace_sequence_7[24]. writing values in the trace control scan chain has the same effect as writing the registers from the cpu. in particular when the event count field is written both the current and maximum count get written. the tracecurcnt instruction allows the current event counts to be read without forcing an update. the read-only trace current count scan chain has the order shown in table 304 . table 304: trace control scan chain bits register description 31:0 trace_event_0[31:0] trace event registers (see table46onpage72 ). 63:32 trace_event_1[31:0] 95:64 trace_event_2[31:0] 127:96 trace_event_3[31:0] 152:128 trace_sequence_0[24:0] trace sequence registers (see table47onpage74 ). 177:153 trace_sequence_1[24:0] 202:178 trace_sequence_2[24:0] 227:203 trace_sequence_3[24:0] 259:228 trace_event_4[31:0] trace event registers (see table46onpage72 ). 291:260 trace_event_5[31:0] 323:292 trace_event_6[31:0] 355:324 trace_event_7[31:0] 380:356 trace_sequence_4[24:0] trace sequence registers (see table47onpage74 ). 405:381 trace_sequence_5[24:0] 430:406 trace_sequence_6[24:0] 455:431 trace_sequence_7[24:0] table 305: trace current count scan chain bits register description 7:0 trace_event_cnt_0[7:0] current count for trace event registers (see table46onpage72 ). 15:8 trace_event_cnt_1[7:0] 23:16 trace_event_cnt_2[7:0] 31:24 trace_event_cnt_3[7:0] 39:32 trace_event_cnt_4[7:0] 47:40 trace_event_cnt_5[7:0] 55:48 trace_event_cnt_6[7:0] 63:56 trace_event_cnt_7[7:0] user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 431 processmon instruction the processmon instruction selects the ring oscillator register for scan in and out. when the instruction is selected, it enables the ring oscillator pointed to by 9:8 of the data register. when this instruction is selected the counter only counts while debug_l pin is asserted. ring oscillators will run at less than 1 ghz. this is for broadcom use only. b oundary s can r egister each pin on the part with the exception of coldre s_l, reset_l, tms, tdo, tdi, trst_l and tck, can be controlled by the boundary scan register. the boundary scan register is selected between tdi and tdo when intest or extest instructions are set in the instruction register. when the tap controller traverses the capture-dr state, the inputs are sampled into the shadow register. during the shift-dr state of the tap controller the contents of the boundary scan shadow register are shifted in between tdi and tdo. when the update-dr state is traversed, the contents of the bsr gets the contents of the shadow register. this allows the user to scan in new contents while the old contents of the bsr are still being held at the outputs. during extest, outputs are driven by the bsr instead of the normal internal signals. during intest the inputs to the part are driven by the bsr instead of the pins. table 306: ring oscillator scan chain bits name description 15:0 count selected counter value. 18:16 sel oscillator select. 19 enable high to enable counter bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 432 section 15: jtag and debug document 1250_1125-um100-r figure 85 shows an example of the boundary scan register and the shadow register for most of the pins on the part. all the pins apart from hypertransport use this input/output pin building block. it consists of three bc_1 scan cells, one for the output, one for the output enable and one for the input. the mode signal causes the jtag to drive both the intest and extest data. figure 85: jtag boundary scan register block tdi out shift_dr mode pad out enable input mode tdo update_dr clock_dr shift_dr user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 433 to use the boundary scan and extest to test board connectivity the following steps should be performed: 1 the tap controllers of both parts under test are set to the extest instruction. 2 the desired pattern on the output pins is shifted into the bsr shadow register. 3 the update-dr state is traversed. 4 the capture-dr state of the target part is traversed. 5 the contents of the shadow register in the target part is scanned out and then compared to expected results. to use boundary scan and intest to run test vectors against the part the following steps should be performed: 1 the instruction register for the part is set to the intest instruction. 2 the desired test pattern is scanned into the shadow register. 3 the update-dr state is traversed. 4 the capture-dr state is traversed. 5 the results from the vector are scanned out from the shadow register. at the same time the next test pattern can be scanned in. the differential signals on the hypertransport interfac e are scanned a little differently. all of these are unidirectional, but the signals are also differential and double data rate. the data rate is doubled and the differential is formed in the output pads, the differential is received and the data rate halved in the input pads. figure 86 shows the output cell. in normal operation two bits of data are presented, one for transmission when the clock is high the other when the clock is low. the inverted version of these bits drives the negative output of the differential pair. the scan function uses two bc_1 cells, one drives each of the pins, but rather than the pin data they monitor the single data rate version of the data. thus when performing extest the two pins are separate (although they should be driven as inverses to guarantee correct reception), but when scanning out vectors the data for both edges of the clock can be captured. figure 86: jtag hypertransport output boundary scan block tdi out_clk_h ldt_tx_clk mode tx_p update_dr clock_dr tx_n shift_dr tdo out_clk_l bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 434 section 15: jtag and debug document 1250_1125-um100-r the hypertransport input block, shown in figure 87 , is similar. it uses two bc_1 cells to monitor the two pins. however, these will always be inverses when a correct differential signal is received. the outputs of the bc_1 cells can be used to drive the single data rate version of the data into the part simplifying intest vector injection. figure 87: jtag hypertransport input boundary scan block the order of the input/output pins are shown in the bsdl file for the part. bsrmode - h olding b oundary s can a ctive using the normal jtag definition it is not possible to keep the boundary scan register active (driving pins or into the part) and scan other internal registers, because the boundary scan must be made inactive when a non- bsr instruction is scanned in to the instruction register. the large ammount of internal state in the part makes it useful to be able to do this so the bsrmode instruction has been added. if the bsrmode instruction is used after extest, clamp or intest then the bsr mode is maintained (keeping the signals driven from the bsr) even if another jtag instruction is used. this allows any number of other chains to be scanned while the bsr values are held. if extest, clamp or intest is followed by any instruction other than bsrmode the bsr mode is removed (per the standard jtag behaviour). after bsrmode has been used its state should be cleared by performing one of the bsr instructions followed by a non-bsr instruction. in_negedge intest tdo update_dr clock_dr shift_dr in_posedge mode ldt_rx_clk tdi rx_n rx_p user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 435 p rocessor and p robe a ccess the jtag probe can act as both a master and a slave on the zbbus. as a master, the probe can initiate any bus transaction. as a slave, the probe responds to accesses in the ejtag memory range 00_1000_0000 to 00_1001_ffff . (this address range will be accessed by the cpu using the alternative debug vector at va ffff_ffff_b000_0480 .) at any time the probe can either be a master or a slave, however it is possible for an external debugger to switch between the two modes to support both processor accesses to the probe and probe accesses to memory. probe accesses are controlled by three jtag registers: the address register, the data register and the control register. these are described in the subsequent sections. jtag commands are provided for scanning these registers individually or as a concatenated chain. there are two control register bits that set the behavior of the probe agent. the proben bit enables accesses to the ejtag range and the masl bit selects if the probe is a master or a slave. table 307 shows the behavior for the possible cases. table 307: cpu and probe accesses proben masl cpu access to 00_1000_0000 - 00_1001_ffff probe access to zbbus 0 0 probe memory disabled. read returns zeros, writes are discarded. master mode disabled. 0 1 probe memory disabled. read returns zeros, writes are discarded. master mode active. the probe can run zbbus cycles. 1 0 probe memory active. reads and writes are serviced by the probe. the ejtag control register should be scanned to detect cpu requests. master mode disabled. 1 1 probe accesses delayed. reads and writes are blocked and will be serviced when masl is set to zero. master mode active. the probe can run zbbus cycles. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 436 section 15: jtag and debug document 1250_1125-um100-r figure 88: example jtag probe flowchart an external debugger connected to the jtag probe can use both master and slave accesses to communicate with the part. an example flow is shown in figure 88 . normally the debugger will scan out the control register and service cpu requests. when it needs to run an access (for example to read memory) it will scan in the control register with the masl bit set. a check needs to be done for cpu accesses that may have arrived while the mode was being changed, once they are serviced the interface is ready for the master access. need jtag scan out scan in/out to zbbus? ejtag control register pracc bit = 1? service cpu access y n n y pracc bit = 1? service cpu access run jtag bus cycle ejtag control register with masl = 1 scan out ejtag control register pracc bit = 1 n y n y more jtag cycles needed? scan in/out ejtag control register with masl=0 n y user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 437 p rocessor a ccesses to the jtag s pace when the jtag probe is configured for slave accesses, an access to the jtag range ( 00_1000_0000 to 00_1001_ffff ) is responded to by the debugger. if the cpu is set to use the alternate debug vector then a debug exception will cause it to fetch instructions from 00_1000_0480 . when the cpu does a read from jtag memory, the jtag unit latches the address, bus command, cache attributes and the byte enables from the request into the scannable address register. the jtag unit then sets the pracc bit to 1. the debugger software will be scanning out the ejtag control register, and will see the pracc bit set. it will then scan out the address register, decode a_cmd as a read and fetch the data in the debugger memory, and then scan the data, properly aligned, into the data register. it will then scan in the control register with the pracc bit cleared. the jtag unit will then terminate the bus transaction with a data cycle on the bus, containing the data, dcode and modified flag from the data register. when the cpu does a write to jtag memory, the jtag unit latches the address, bus command, cache attributes and the byte enables from the request into the scannable address register and the data, dcode, responder id and modified flag into the data register. the jtag unit then sets the pracc bit to 1. the debugger software will be scanning out the ejtag control register, and will see the pracc bit set. it will then scan out the address register, decode a_cmd as a write, scan the data register, and write the data in the debugger memory. it will then scan in the control register with the pracc bit cleared causing the jtag unit to free up the buffers and allow more transactions. the cpu can map the jtag space cacheable non-coherent or uncacheable. it must not be mapped cacheable coherent, or the behavior of the system becomes undefined. p robe a ccesses to the zb bus when the masl bit is set in the ejtag control regist er, the probe can master the zbbus and access any area of system memory. a write to system memory is done by scanning into the address register the address, byte enables, command and cache attribute bits. the data, dcode and modified flag are scanned in to the data register. the four responder id bits that are scanned into the data register are ignored, the scd agent id is always used for a request from the jtag unit. when the pbacc and pw bits are set in the ejtag control register the write will be initiated, and the pbacc bit will be cleared when it has completed. a read from system memory is done by scanning into the address register the address, byte enables, command and cache attribute bits. the access is started by scanning a 1 into the pbacc bit, and a 0 into the pw bit. the ejtag unit then makes a read request on the bus and when the transaction has finished, the data, dcode, responder id and modified flag will be returned in the data register, and the pbacc bit will be cleared. the probe should keep scanning out the control register until it sees that the pbacc bit has been cleared. it then can scan out the data register. note that if probeen is 1, a master access should not be made to an address serviced by the scd, since these will deadlock. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 438 section 15: jtag and debug document 1250_1125-um100-r a ddress r egister the address register is 77 bits long and contains the address bits, byte enables, bus command and cache attributes. to maintain coherency the cache attributes must be set correctly for the address so snoop responses are correct (in some situations the debugger may want to use different attributes but it must do so with care, for example a cacheable non-coherent read to a memory address can be used to force data to come from the l2 cache or memory, never a processor l1 cache, and an uncacheable read from a memory address will force the data to come from memory). the address is for a 32 byte cache block, the byte enables complete selection within the block. table 308 shows the address register, which is scanned starting with the lsb. d ata r egister the data register contains 256 data bits, the status/error code, the id of the agent that put the data on the zbbus, the modified flag, and (on reads) the response phase information for the transaction. the register is shown in table 309 , and is scanned from lsb to msb. the mapping from the byte enables in the address register to bits in this register is fixed; however, the byte address associated with each byte lane depends on the system endian mode as shown in table 5 on page 24 . table 308: jtag address register scan chain bits zbbus signal (see table 2 on page 20 ) description 34:0 a_ad[39:5] address 66:35 a_be[31:0] byte enables. indicate which byte lanes are valid in the data register, see table 5 on page 24 for the mapping from byte enable to byte address. 69:67 a_cmd[2:0] command. see table 3 on page 22 . 71:70 a_l1ca[1:0] l1 cacheability attribute. see table 4 on page 23 . 72 a_l2ca l2 cache allocate request. 76:73 a_id[9:6] requester agent id (see table 1 on page 20 ). these bits are only valid when the probe is the slave, in master mode the scd agent id will be used for the transaction. table 309: data register scan chain bits zbbus signal (see table 2 on page 20 ) description 255:0 d_da[255:0] data. only the byte lanes that had byte enables set contain valid data. 258:256 d_code[2:0] data status/error code (see table 6 on page 24 ). 259 d_mod set to indicate the data is modified (dirty). 263:260 d_rsp[3:0] id of agent putting the data on the zbbus. this is a read only field, bits scanned in will be ignored. 264 r_l2hit response indicating block is in the l2 cache (read only, only valid for probe master reads). 270:265 r_exc[5:0] response indicating block is exclusive in an agent (read only, only valid for probe master reads). 276:271 r_shd[5:0] response indicating block is shared by an agent (read only, only valid for probe master reads). user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 439 ejtag c ontrol r egister this is a 12 bit register to control the various operations of the debug support modules.this register is selected by shifting in the control instruction. bits in the ejtag control register can be set/cleared by shifting in data; status is read by shifting out this register. this ejtag control register can only be accessed by the tap interface. table 310: ejtag control register bit name description use reset value 0 dm0 debug mode 0. this bit indicates the value of the eden signal from cpu0. when this bit is set, it indicates that cpu0 is signalling a debug event (see sb-1 cpu user manual). this bit is read only, and any writes to it are ignored. rx 1 dm1 debug mode 1. this bit indicates the value of the eden signal from cpu1. when this bit is set, it indicates that cpu1 is signalling a debug event (see sb-1 cpu user manual). this bit is read only, and any writes to it are ignored. on the BCM1125/h this bit is not used and reads are unpredictable. rx 2 ejtag break0 setting this bit to 1 causes the di nt pin to cpu0 to be set. this allows the probe to signal a debug interrupt to cpu0. the bit must be cleared to remove the interrupt. r/w 0 3 ejtag break1 setting this bit to 1 causes the di nt pin to cpu1 to be set. this allows the probe to signal a debug interrupt to cpu1.the bit must be cleared to remove the interrupt. on the BCM1125/h this bit is not used. r/w 0 4 prtrap0 probe trap0. setting this bit to 1 forces the dbboot signal to cpu0 to 1. this allows the probe to force cpu0 into debug mode upon the next deassertion of reset. this bit is set on the update-ir state of the ejtagboot instruction. it is reset on the update-ir state of the normalboot instruction or by asserting the trst_l pin or by a rising edge of tck when the tap controller is in the test-logic-reset state. this bit can also be set or cleared by scanning a 1 or 0 into this bit. r/w 0 5 prtrap1 probe trap1. this bit performs the same way as prtrap0, except it does so for cpu1. on the BCM1125/h this bit is not used. r/w 0 6 proben probe enable. setting this bit to 1 will indicate that ejtag memory is handled by the probe, so processor accesses are answered. 0: the probe does not handle ejtag memory transactions. accesses to the ejtag memory space always returns 0. 1: the probe does handle ejtag memory transactions. when this bit is set the masl bit is used to determine if the probe is acting as bus master or slave. see discussion in section: ?processor and probe access? on page 435 . note that setting the prtrap bits without this bit set causes an invalid state. the ejtagboot instruction will set this bit to 1. the normalboot instruction will clear this bit. this bit is also cleared by asserting trst_l or by a rising edge of tck while in the test-logic-reset state. r/w 0 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 440 section 15: jtag and debug document 1250_1125-um100-r 7 pracc processor access. read value of this bit indicates if a processor access (pa) to the ejtag memory is pending: 0: no pending processor access. 1: pending processor access. the probe control software must clear this bit to 0 to indicate the end of the pa. write of 1 is ignored. r/w 0 8 pw processor access write. this bit is not used. r/w x 9 pbacc probe initiated transaction. when set this bit indicates a probe initiated transaction is in progress. the probe sets this bit to indicate to the jtag unit that the probe is initiating a transaction. the jtag unit clears this bit when the transaction has been completed. this bit can only be set if the proben bit is cleared. probe initiated transactions can occur only if the masl bit is set. 0: no pending probe access. 1: pending probe access. if the probe writes a zero to this bit it is ignored. the only way the bit can be set is by the probe writing a 1, the only way the bit can be cleared is by the jtag unit clearing it. r/w 0 10 masl probe master/slave. when set this bit indicates the probe can initiate a transaction, if proben is set then cpu accesses will be blocked until this bit is clear. when clear cpu transactions will be accepted if proben is set. 0: cpu accesses accepted. 1: probe can initiate a bus transaction. r/w 0 11 clkstop clock stop flag. this bit is for broadcom use only. r/o 0 table 310: ejtag control register (cont.) bit name description use reset value user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 441 d ifferences from ejtag 2.5 (f eb . 22, 2000) s pecification the bcm1250 has some differences from the ejtag 2.5 due to support for the dual processor configuration and system level debug access. a summary, with reference to the section numbers in the ejtag 2.5 (feb. 22, 2000) specification: 2.2.2 the bcm1250 has no dseg (a kseg1 address is used for probe serviced accesses) 2.2.2.1 n/a 2.2.2.2 n/a 2.2.3.2 the random register continues to run in debug mode 2.3.2 alternate vector location is ffff_ffff_b000_0480 - set by sw in edebug register - set by dbboot signal from jtag tap (in ejtag control register) 2.3.5/2.3.6 hardware breakpoints/watchpoints can be done in extended debug mode using the regular watch registers not special ones. 2.3.7 watch register exceptions are precise for both data and instructions 2.6.3 processor reset is done through system config register not ejtag control 2.6.4 rocc is not supported. 3 there is no dcr (dseg is not supported) 4 there are no special debug hardware breakpoints. in extended debug mode the cp0 watch registers can be used to provide one hardware data break and one hardware instruction breakpoint. 5 a single tap is shared by the two processors and the system logic. 5.5.3 the data register is 277 bits (contains zbbus data + info) bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 442 section 15: jtag and debug document 1250_1125-um100-r 5.5.4 the address register is 77 bits (contains zbbus address + cmd) 5.5.5 rocc - not implemented psz - not implemented, size in address register doze - not implemented halt - not implemented perrst - use system config register for resets prnw - not used pracc - supported prrst - use system config register for resets proben - supported (works with additional masl bit to set direction) probtrap - two copies, one per cpu. also causes ejtag boot on reset ejtagbrk - two copies, one per cpu, level sensitive probe must clear dm - two copies. but shows cpu eden signal rather than dm 5.6.3 rocc is not supported 5.6.4 processor access is through physical address 00_1000_0000 - 00_1001_ffff and uses zbbus request there is an additional mode for allowing the probe to initiate bus requests to memory or memory mapped i/o. 7.1.2 external interrupt possible through debug_l pin but the driver must be open collector or open drain. 7.1.2 the probe rst signal can be connected to reset_l. user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 15: jtag and debug page 443 this page is left blank for notes bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 444 section 15: jtag and debug document 1250_1125-um100-r this page is left blank for notes user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 445 section 16: reference i nternal r egister a ddresses by f unction this section lists the registers and address assignments, per zbbus agent. in the electronic version of the document the table/page column provides a hyperlink to the table that defines the register. note: the following table details the specific addresses and names of each register. each register is 1 byte, 2 bytes, 4 bytes or 8 bytes. registers can be read or written as double-word (8 bytes), word (4 bytes), 2 byte or signal byte access. reads that are wider than the defined width or the register will return unpredictable data in the bits that are not defined. the address used to access the register will need to be adjusted if the system is running in big endian mode. see section: ?internal registers? on page 11 for details. configuration registers should be mapped in uncacheable space, so transactions will never be wider than 8 bytes (and will never span more than an single 8 byte aligned range). reading registers marked ?write only? will give unpredictable results. writes to ?read only? registers will be ignored. table 311: internal register addresses by function name address table/ page description memory controller mc_config_0 00_1005_1100 72/135 channel 0 attributes. mc_dramcmd_0 00_1005_1120 75/139 channel 0 sdram command. mc_drammode_0 00_1005_1140 76/139 channel 0 sdram mode. mc_timing1_0 00_1005_1160 77/140 channel 0 sdram timing 1. mc_timing2_0 00_1005_1180 78/141 channel 0 sdram timing 2. mc_cs_start_0 00_1005_11a0 79/141 channel 0 cs[3:0] start address. mc_cs_end_0 00_1005_11c0 80/141 channel 0 cs[3:0] end+1 address. mc_interleave_0 00_1005_11e0 81/142 channel 0 interleaved cs position. mc_cs0_row_0 00_1005_1200 82/142 channel 0 cs0 row address bits. mc_cs0_col_0 00_1005_1220 83/142 channel 0 cs0 column address bits. mc_cs0_ba_0 00_1005_1240 84/143 channel 0 cs0 bank select. mc_cs1_row_0 00_1005_1260 82/142 channel 0 cs1 row address bits. mc_cs1_col_0 00_1005_1280 83/142 channel 0 cs1 column address bits. mc_cs1_ba_0 00_1005_12a0 84/143 channel 0 cs1 dram bank select. mc_cs2_row_0 00_1005_12c0 82/142 channel 0 cs2 row address bits. mc_cs2_col_0 00_1005_12e0 83/142 channel 0 cs2 column address bits. mc_cs2_ba_0 00_1005_1300 84/143 channel 0 cs2 dram bank select. mc_cs3_row_0 00_1005_1320 82/142 channel 0 cs3 row address bits. mc_cs3_col_0 00_1005_1340 83/142 channel 0 cs3 column address bits. mc_cs3_ba_0 00_1005_1360 83/142 channel 0 cs3 dram bank select. bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 446 section 16: reference document 1250_1125-um100-r mc_cs_attr_0 00_1005_1380 85/143 channel 0 cs[3:0]attribute. mc_test_data_0 00_1005_1400 86/144 channel 0 ecc error set data bits. mc_test_ecc_0 00_1005_1420 87/144 channel 0 ecc error set ecc bits. mc_clock_cfg_0 00_1005_1500 74/138 channel 0 memory clock ratio. mc__1 00_1005_2000 ... 00_1005_2600 see _0 above memory controller channel 1 configuration (at memory controler 0 + 1000). l2 controller l2_read_address 00_1004_0018 56/100 read only. last address/tag in a read (for testing) l2_ecc_address 00_1004_0038 56/100 read only. last address with ecc error (correctable or not). l2_misc_value 00_1004_0058 57/100 read only. periph_rev3 and later. value of l2 hidden registers. l2_way_disable 00_1004_1x00 /91 accesses made to this range of addresses will write the value x to l2_wayen[3:0] register. if l2_wayen[i] is clear way i is removed from the l2 replacement algorithm. see section: ?using the l2 cache as memory? on page 91 l2_cache_disable 00_1004_2x00 /94 accesses made to this range of addresses will write the value x to l2_cache_disable[3:0] register. see section: ?reduced cache size? on page 94 . l2_misc_config 00_1004_3x00 /99 accesses made to this range of addresses will write the value x to l2_misc_config[3:0] register. see section: ?cache configuration register? on page 99 . pci host bridge type 00 pci header 00_fe00_0000 - 00_fe00_00ff 127/236 configuration space bus=0,dev=0. hypertransport host bridge type 01 pci header 00_fe00_0800 - 00_fe00_08ff 140/244 configuration space bus=0,dev=1. ethernet dma and macs mac_tx_byte_0 00_1006_4000 167/288 rmon transmit byte counter. mac_collisions_0 00_1006_4008 167/288 rmon total collisions. mac_late_col_0 00_1006_4010 167/288 rmon late collisions. mac_ex_col_0 00_1006_4018 167/288 rmon excessive collisions. mac_fcs_error_0 00_1006_4020 167/288 rmon packets tx with bad fcs. mac_tx_abort_0 00_1006_4028 167/288 rmon transmit packets aborted. mac_tx_bad_0 00_1006_4038 167/288 rmon total of bad tx packets. mac_tx_good_0 00_1006_4040 167/288 rmon total sucessfully transmitted packets. mac_tx_runt_0 00_1006_4048 167/288 rmon total runt packets transmitted. mac_tx_oversize_0 00_1006_4050 167/288 rmon total oversize packets transmitted. table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 447 mac_rx_bytes_0 00_1006_4080 167/288 rmon total received bytes. mac_rx_mcast_0 00_1006_4088 167/288 rmon total received multicast packets. mac_rx_bcast_0 00_1006_4090 167/288 rmon total received broadcast packets. mac_rx_bad_0 00_1006_4098 167/288 rmon total received bad packets. mac_rx_good_0 00_1006_40a0 167/288 rmon total received good packets. mac_rx_runt_0 00_1006_40a8 167/288 rmon total runt packets received. mac_rx_oversize_0 00_1006_40b0 167/288 rmon total oversize packets received. mac_rx_fcs_error_0 00_1006_40b8 167/288 rmon total packets received with bad fcs. mac_rx_length_error_0 00_1006_40c0 167/288 rmon total packets received with length error. mac_rx_code_error_0 00_1006_40c8 167/288 rmon total packets received with code error. mac_rx_align_error_0 00_1006_40d0 167/288 rmon total packets received with align error. mac_cfg_0 00_1006_4100 176/301 ethernet interface configuration register. mac_thrsh_cfg_0 00_1006_4108 179/306 ethernet interface fifo threshold configuration register. mac_vlantag_0 00_1006_4110 181/309 vlan tag for insertion into packets on transmit mac_frame_cfg_0 00_1006_4118 180/307 ethernet interface mac frame configuration. mac_rx_fifo_ptrs_0 00_1006_4120 186/313 mac fifo pointers (debug, read only). mac_tx_fifo_ptrs_0 00_1006_4128 186/313 mac fifo pointers. (debug, read only.) mac_adfilter_cfg_0 00_1006_4200 192/315 mac receive address filter configuration register. mac_ethernet_addr_0 00_1006_4208 190/314 mac source ethernet address for insertion during transmission. mac_type_cfg_0 00_1006_4210 191/315 mac packet type table for receive packet comparisons. mac_hash0_0 00_1006_4240 189/314 address filter hash map. mac_hash1_0 00_1006_4248 189/314 address filter hash map. mac_hash2_0 00_1006_4250 189/314 address filter hash map. mac_hash3_0 00_1006_4258 189/314 address filter hash map. mac_hash4_0 00_1006_4260 189/314 address filter hash map. mac_hash5_0 00_1006_4268 189/314 address filter hash map. mac_hash6_0 00_1006_4270 189/314 address filter hash map. mac_hash7_0 00_1006_4278 189/314 address filter hash map. mac_addr0_0 00_1006_4280 187/313 address filter exact match. mac_admask0_0 00_1006_4218 188/314 address filter exact match mask register (periph_rev3). mac_addr1_0 00_1006_4288 187/313 address filter exact match. mac_admask1_0 00_1006_4220 188/314 address filter exact match mask register (periph_rev3). mac_addr2_0 00_1006_4290 187/313 address filter exact match. mac_addr3_0 00_1006_4298 187/313 address filter exact match. mac_addr4_0 00_1006_42a0 187/313 address filter exact match. table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 448 section 16: reference document 1250_1125-um100-r mac_addr5_0 00_1006_42a8 187/313 address filter exact match. mac_addr6_0 00_1006_42b0 187/313 address filter exact match. mac_addr7_0 00_1006_42b8 187/313 address filter exact match. mac_chup0_0 00_1006_4300 193/317 receive dma channel select msb. mac_chup1_0 00_1006_4308 193/317 receive dma channel select msb. mac_chup2_0 00_1006_4310 193/317 receive dma channel select msb. mac_chup3_0 00_1006_4318 193/317 receive dma channel select msb. mac_chlo0_0 00_1006_4320 193/317 receive dma channel select lsb. mac_chlo1_0 00_1006_4328 193/317 receive dma channel select lsb. mac_chlo2_0 00_1006_4330 193/317 receive dma channel select lsb. mac_chlo3_0 00_1006_4338 193/317 receive dma channel select lsb. mac_enable_0 00_1006_4400 177/305 mac enable register. mac_status_0 00_1006_4408 182/309 mac status/error register (read only, read clears). mac_status1_0 00_1006_4430 183/312 mac status/error register (read only, read clears ch 1). mac_int_mask_0 00_1006_4410 185/313 mac interrupt mask register. dma_asic_addr_mac_0 00_1006_4418 94/166 asic mode base address. mac_txd_ctl_0 00_1006_4420 178/305 transmit dma control register. mac_mdio_0 00_1006_4428 194/317 mdio pin control register. mac_debug_status_0 00_1006_4448 184/312 mac status/error register (debug, read only, no side effects). dma_config0_mac_0_rx_ch_0 00_1006_4800 91/163 dma config 0 register. dma_config1_mac_0_rx_ch_0 00_1006_4808 92/164 dma config 1 register. dma_dscr_base_mac_0_rx_ch_0 00_1006_4810 93/166 dma descriptor base register. dma_dscr_cnt_0_rx_ch_0 00_1006_4818 95/166 dma descriptor count. dma_dscr_a_mac_0_rx_ch_0 00_1006_4820 96/167 dma current descriptor a. dma_dscr_b_mac_0_rx_ch_0 00_1006_4828 97/167 dma current descriptor b. dma_cur_dscr_addr_mac_0_rx_ ch_0 00_1006_4830 98/167 dma current descriptor address. dma_oodpktlost_mac_0_rx_ch_0 00_1006_4838 99/168 dma packet lost counter. (periph_rev3) dma__mac_0_rx_ch_1 00_1006_4900 rx channel 1 at rx channel 0 + 100. dma__mac_0_tx_ch_0 00_1006_4c00 tx channel 0 at rx channel 0 + 400. dma__mac_0_tx_ch_1 00_1006_4d00 tx channel 1 at rx channel 0 + 500. mac_1 00_1006_5000 mac 1 registers (+1000 from mac_0 registers). mac_2 00_1006_6000 mac 2 registers (+2000 from mac_0 registers). table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 449 serial ports duart_mode_reg_1a 00_1006_0100 197/326 mode register 1 port a mr1a. duart_mode_reg_2a 00_1006_0110 198/326 mode register 2 port a mr2a. duart_status_a 00_1006_0120 200/327 status register port a (read only). duart_clk_sel_a 00_1006_0130 201/328 clock select register port a. duart_full_ctl_a 00_1006_0140 202/328 full control port a. duart_cmd_a 00_1006_0150 199/327 command register port a. duart_rx_hold_reg_a 00_1006_0160 203/328 rx holding register port a (read only, read pops character from fifo). duart_tx_hold_reg_a 00_1006_0170 204/329 tx holding register port a (write only). duart_opcr_a 00_1006_0180 211/331 output port control register alias that only alters port a bits. duart_aux_ctrl_a 00_1006_0190 213/331 aux control register alias that only alters port a bits. duart_mode_reg_1b 00_1006_0200 197/326 mode register 1 port b. duart_mode_reg_2b 00_1006_0210 198/326 mode register 2 port b. duart_status_b 00_1006_0220 200/327 status register port b (read only). duart_clk_sel_b 00_1006_0230 201/328 clock select register port b. duart_full_ctl_b 00_1006_0240 202/328 full control port b. duart_cmd_b 00_1006_0250 199/327 command register port b. duart_rx_hold_reg_b 00_1006_0260 203/328 rx holding register port b (read only, read pops character from fifo). duart_tx_hold_reg_b 00_1006_0270 204/329 tx holding register port b (write only). duart_opcr_b 00_1006_0280 211/331 output port control register alias that only alters port b bits. duart_aux_ctrl_b 00_1006_0290 213/331 aux control register alias that only alters port b bits. duart_inport_chng 00_1006_0300 206/329 input port change register (read only, read clears). duart_aux_cntrl 00_1006_0310 212/331 aux control register. duart_isr_a 00_1006_0320 215/332 interrupt status register port a (read only). duart_imr_a 00_1006_0330 218/333 interrupt mask register port a. duart_isr_b 00_1006_0340 216/332 interrupt status register port b (read only). duart_imr_b 00_1006_0350 219/333 interrupt mask register port b. duart_out_port 00_1006_0360 222/334 output port register (write only). duart_opcr 00_1006_0370 210/330 output port control. duart_in_port 00_1006_0380 205/329 input port state (read only). duart_isr 00_1006_0390 214/332 full interrupt status (read only). duart_imr 00_1006_03a0 217/333 full interrupt mask. duart_set_opr 00_1006_03b0 220/334 output port register bit set (write only). duart_clear_opr 00_1006_03c0 221/334 output port register bit clear (write only). duart_inport_chng_a 00_1006_03d0 208/330 input port change register for channel a (read only, read clears channel a change state) table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 450 section 16: reference document 1250_1125-um100-r duart_inport_chng_b 00_1006_03e0 209/330 input port change register for channel b (read only, read clears channel b change state) duart_inport_chng_debug 00_1006_03f0 207/330 alias of input port change register with no read side effects. (read only) dma_config0_ser_0_rx 00_1006_0400 91/163 receive dma control register. dma_config1_ser_0_rx 00_1006_0408 92/164 receive dma control register. dma_dscr_base_ser_0_rx 00_1006_0410 93/166 receive dma descriptor base address. dma_dscr_cnt_ser_0_rx 00_1006_0418 95/166 receive dma descriptor count . dma_cur_dscr_a_ser_0_rx 00_1006_0420 96/167 receive dma current descriptor a (read only). dma_cur_dscr_b_ser_0_rx 00_1006_0428 97/167 receive dma current descriptor b (read only). dma_cur_daddr_ser_0_rx 00_1006_0430 98/167 receive dma current descriptor address (read only). dma_config0_ser_0_tx 00_1006_0480 91/163 transmit dma control register. dma_config1_ser_0_tx 00_1006_0488 92/164 transmit dma control register. dma_dscr_base_ser_0_tx 00_1006_0490 93/166 transmit dma descriptor base address. dma_dscr_cnt_ser_0_tx 00_1006_0498 95/166 transmit dma descriptor count. dma_cur_dscr_a_ser_0_tx 00_1006_04a0 96/167 transmit dma current descriptor a (read only). dma_cur_dscr_b_ser_0_tx 00_1006_04a8 97/167 transmit dma current descriptor b (read only). dma_cur_daddr_ser_0_tx 00_1006_04b0 98/167 transmit dma current descriptor address (read only). ser_mode_0 00_1006_0500 231/353 mode select. ser_minfrm_sz_0 00_1006_0508 237/355 min frame size. ser_maxfrm_sz_0 00_1006_0510 238/356 max frame size. ser_addr_mask_0 00_1006_0518 243/358 address mask. ser_usr0_addr_0 00_1006_0520 244/358 match address 0. ser_usr1_addr_0 00_1006_0528 244/358 match address 1. ser_usr2_addr_0 00_1006_0530 244/358 match address 2. ser_usr3_addr_0 00_1006_0538 244/358 match address 3. ser_cmd_0 00_1006_0540 233/354 command ser_tx_rd_thrsh_0 00_1006_0560 235/355 transmit fifo read threshold. ser_tx_wr_thrsh_0 00_1006_0568 234/355 transmit fifo write threshold. ser_rx_rd_thrsh_0 00_1006_0570 236/355 receive fifo read threshold. ser_line_mode_0 00_1006_0578 232/353 line interface configuration register. ser_dma_enable_0 00_1006_0580 239/356 dma channel enable register. ser_status_0 00_1006_0588 240/356 serial interface and dma status (read only, read clears). ser_int_mask_0 00_1006_0590 242/357 interrupt mask. dma_asic_addr_ser_0 00_1006_0598 94/166 asic mode address. ser_debug_status_0 00_1006_05a8 241/357 serial interface and dma status (read only, no side effects). ser_tx_byte_lo_0 00_1006_05c0 246/359 serial interface transmit byte count (low 16 bits). table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 451 ser_tx_byte_hi_0 00_1006_05c8 246/359 serial interface transmit byte count (high 16 bits). ser_rx_byte_lo_0 00_1006_05d0 246/359 serial interface receive byte count (low 16 bits). ser_rx_byte_hi_0 00_1006_05d8 246/359 serial interface receive byte count (high 16 bits). ser_tx_underrun_0 00_1006_05e0 246/359 serial interface transmit underrun count. ser_rx_overflow_0 00_1006_05e8 246/359 serial interface receive overflow count. ser_rx_errors_0 00_1006_05f0 246/359 serial interface receive error packet count. ser_rx_badaddr_0 00_1006_05f8 246/359 serial interface receive address mismatch count. ser_rx_table0_0 00_1006_0600 245/358 sequence table. ser_rx_table1_0 00_1006_0608 245/358 sequence table. ser_rx_table2_0 00_1006_0610 245/358 sequence table. ser_rx_table3_0 00_1006_0618 245/358 sequence table. ser_rx_table4_0 00_1006_0620 245/358 sequence table. ser_rx_table5_0 00_1006_0628 245/358 sequence table. ser_rx_table6_0 00_1006_0630 245/358 sequence table. ser_rx_table7_0 00_1006_0638 245/358 sequence table. ser_rx_table8_0 00_1006_0640 245/358 sequence table. ser_rx_table9_0 00_1006_0648 245/358 sequence table. ser_rx_table10_0 00_1006_0650 245/358 sequence table. ser_rx_table11_0 00_1006_0658 245/358 sequence table. ser_rx_table12_0 00_1006_0660 245/358 sequence table. ser_rx_table13_0 00_1006_0668 245/358 sequence table. ser_rx_table14_0 00_1006_0670 245/358 sequence table. ser_rx_table15_0 00_1006_0678 245/358 sequence table. ser_tx_table0_0 00_1006_0700 245/358 sequence table. ser_tx_table1_0 00_1006_0708 245/358 sequence table. ser_tx_table2_0 00_1006_0710 245/358 sequence table. ser_tx_table3_0 00_1006_0718 245/358 sequence table. ser_tx_table4_0 00_1006_0720 245/358 sequence table. ser_tx_table5_0 00_1006_0728 245/358 sequence table. ser_tx_table6_0 00_1006_0730 245/358 sequence table. ser_tx_table7_0 00_1006_0738 245/358 sequence table. ser_tx_table8_0 00_1006_0740 245/358 sequence table. ser_tx_table9_0 00_1006_0748 245/358 sequence table. ser_tx_table10_0 00_1006_0750 245/358 sequence table. ser_tx_table11_0 00_1006_0758 245/358 sequence table. ser_tx_table12_0 00_1006_0760 245/358 sequence table. ser_tx_table13_0 00_1006_0768 245/358 sequence table. table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 452 section 16: reference document 1250_1125-um100-r ser_tx_table14_0 00_1006_0770 245/358 sequence table. ser_tx_table15_0 00_1006_0778 245/358 sequence table. dma_config0_ser_1_rx 00_1006_0800 91/163 receive dma control register. dma_config1_ser_1_rx 00_1006_0808 92/164 receive dma control register. dma_dscr_base_ser_1_rx 00_1006_0810 93/166 receive dma descriptor base address. dma_dscr_count_ser_1_rx 00_1006_0818 95/166 receive dma descriptor count. dma_cur_dscr_a_ser_1_rx 00_1006_0820 96/167 receive dma current descriptor a (read only). dma_cur_dscr_b_ser_1_rx 00_1006_0828 97/167 receive dma current descriptor b (read only). dma_cur_daddr_ser_1_rx 00_1006_0830 98/167 receive dma current descriptor address (read only). dma_config0_ser_1_tx 00_1006_0880 91/163 transmit dma control register. dma_config1_ser_1_tx 00_1006_0888 92/164 transmit dma control register. dma_dscr_base_ser_1_tx 00_1006_0890 93/166 transmit dma descriptor base address. dma_dscr_count_ser_1_tx 00_1006_0898 95/166 transmit dma descriptor count. dma_cur_dscr_a_ser_1_tx 00_1006_08a0 96/167 transmit dma current descriptor a (read only). dma_cur_dscr_b_ser_1_tx 00_1006_08a8 97/167 transmit dma current descriptor b (read only). dma_cur_daddr_ser_1_tx 00_1006_08b0 98/167 transmit dma current descriptor address (read only). ser_mode_1 00_1006_0900 231/353 mode select. ser_minfrm_sz_1 00_1006_0908 237/355 min frame size. ser_maxfrm_sz_1 00_1006_0910 238/356 max frame size. ser_addr_mask_1 00_1006_0918 243/358 address mask. ser_usr0_addr_1 00_1006_0920 244/358 match address 0. ser_usr1_addr_1 00_1006_0928 244/358 match address 1. ser_usr2_addr_1 00_1006_0930 244/358 match address 2. ser_usr3_addr_1 00_1006_0938 244/358 match address 3. ser_cmd_1 00_1006_0940 233/354 command ser_tx_rd_thrsh_1 00_1006_0960 235/355 transmit fifo read threshold. ser_tx_wr_thrsh_1 00_1006_0968 234/355 transmit fifo write threshold. ser_rx_rd_thrsh_1 00_1006_0970 236/355 receive fifo read threshold. ser_line mode_1 00_1006_0978 232/353 line interface configuration register. ser_dma_enable_1 00_1006_0980 239/356 dma channel enable register. ser_status_1 00_1006_0988 240/356 serial interface and dma status (read only, read clears). ser_int_mask_1 00_1006_0990 242/357 interrupt mask. dma_asic_addr_ser_1 00_1006_0998 94/166 asic mode address. ser_debug_status_1 00_1006_09a8 241/357 serial interface and dma status (read only, no side effects). ser_tx_byte_lo_1 00_1006_09c0 246/359 serial interface transmit byte count (low 16 bits). ser_tx_byte_hi_1 00_1006_09c8 246/359 serial interface transmit byte count (high 16 bits). table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 453 ser_rx_byte_lo_1 00_1006_09d0 246/359 serial interface receive byte count (low 16 bits). ser_rx_byte_hi_1 00_1006_09d8 246/359 serial interface receive byte count (high 16 bits). ser_tx_underrun_1 00_1006_09e0 246/359 serial interface transmit underrun count. ser_rx_overflow_1 00_1006_09e8 246/359 serial interface receive overflow count. ser_rx_errors_1 00_1006_09f0 246/359 serial interface receive error packet count. ser_rx_badaddr_1 00_1006_09f8 246/359 serial interface receive address mismatch count. ser_rx_table0_1 00_1006_0a00 245/358 sequence table. ser_rx_table1_1 00_1006_0a08 245/358 sequence table. ser_rx_table2_1 00_1006_0a10 245/358 sequence table. ser_rx_table3_1 00_1006_0a18 245/358 sequence table. ser_rx_table4_1 00_1006_0a20 245/358 sequence table. ser_rx_table5_1 00_1006_0a28 245/358 sequence table. ser_rx_table6_1 00_1006_0a30 245/358 sequence table. ser_rx_table7_1 00_1006_0a38 245/358 sequence table. ser_rx_table8_1 00_1006_0a40 245/358 sequence table. ser_rx_table9_1 00_1006_0a48 245/358 sequence table. ser_rx_table10_1 00_1006_0a50 245/358 sequence table. ser_rx_table11_1 00_1006_0a58 245/358 sequence table. ser_rx_table12_1 00_1006_0a60 245/358 sequence table. ser_rx_table13_1 00_1006_0a68 245/358 sequence table. ser_rx_table14_1 00_1006_0a70 245/358 sequence table. ser_rx_table15_1 00_1006_0a78 245/358 sequence table. ser_tx_table0_1 00_1006_0b00 245/358 sequence table. ser_tx_table1_1 00_1006_0b08 245/358 sequence table. ser_tx_table2_1 00_1006_0b10 245/358 sequence table. ser_tx_table3_1 00_1006_0b18 245/358 sequence table. ser_tx_table4_1 00_1006_0b20 245/358 sequence table. ser_tx_table5_1 00_1006_0b28 245/358 sequence table. ser_tx_table6_1 00_1006_0b30 245/358 sequence table. ser_tx_table7_1 00_1006_0b38 245/358 sequence table. ser_tx_table8_1 00_1006_0b40 245/358 sequence table. ser_tx_table9_1 00_1006_0b48 245/358 sequence table. ser_tx_table10_1 00_1006_0b50 245/358 sequence table. ser_tx_table11_1 00_1006_0b58 245/358 sequence table. ser_tx_table12_1 00_1006_0b60 245/358 sequence table. ser_tx_table13_1 00_1006_0b68 245/358 sequence table. ser_tx_table14_1 00_1006_0b70 245/358 sequence table. table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 454 section 16: reference document 1250_1125-um100-r ser_tx_table15_1 00_1006_0b78 245/358 sequence table. generic bus io_ext_cfg_0 00_1006_1000 251/374 cs0 interface configuration. io_ext_cfg_1 00_1006_1008 251/374 cs1 interface configuration. io_ext_cfg_2 00_1006_1010 251/374 cs2 interface configuration. io_ext_cfg_3 00_1006_1018 251/374 cs3 interface configuration. io_ext_cfg_4 00_1006_1020 251/374 cs4 interface configuration. io_ext_cfg_5 00_1006_1028 251/374 cs5 interface configuration. io_ext_cfg_6 00_1006_1030 251/374 cs6 interface configuration. io_ext_cfg_7 00_1006_1038 251/374 cs7 interface configuration. io_ext_mult_size_0 00_1006_1100 252/374 cs0 region size in 64kb units. io_ext_mult_size_1 00_1006_1108 252/374 cs1 region size in 64kb units. io_ext_mult_size_2 00_1006_1110 252/374 cs2 region size in 64kb units. io_ext_mult_size_3 00_1006_1118 252/374 cs3 region size in 64kb units. io_ext_mult_size_4 00_1006_1120 252/374 cs4 region size in 64kb units. io_ext_mult_size_5 00_1006_1128 252/374 cs5 region size in 64kb units. io_ext_mult_size_6 00_1006_1130 252/374 cs6 region size in 64kb units. io_ext_mult_size_7 00_1006_1138 252/374 cs7 region size in 64kb units. io_ext_start_addr_0 00_1006_1200 253/375 cs0 region start address (put outside generic bus range to disable). io_ext_start_addr_1 00_1006_1208 253/375 cs1 region start address (put outside generic bus range to disable). io_ext_start_addr_2 00_1006_1210 253/375 cs2 region start address (put outside generic bus range to disable). io_ext_start_addr_3 00_1006_1218 253/375 cs3 region start address (put outside generic bus range to disable). io_ext_start_addr_4 00_1006_1220 253/375 cs4 region start address (put outside generic bus range to disable). io_ext_start_addr_5 00_1006_1228 253/375 cs5 region start address (put outside generic bus range to disable). io_ext_start_addr_6 00_1006_1230 253/375 cs6 region start address (put outside generic bus range to disable). io_ext_start_addr_7 00_1006_1238 253/375 cs7 region start address (put outside generic bus range to disable). io_ext_time_cfg0_0 00_1006_1600 254/375 cs0 timing parameter configuration 0. io_ext_time_cfg0_1 00_1006_1608 254/375 cs1 timing parameter configuration 0. io_ext_time_cfg0_2 00_1006_1610 254/375 cs2 timing parameter configuration 0. io_ext_time_cfg0_3 00_1006_1618 254/375 cs3 timing parameter configuration 0. io_ext_time_cfg0_4 00_1006_1620 254/375 cs4 timing parameter configuration 0. io_ext_time_cfg0_5 00_1006_1628 254/375 cs5 timing parameter configuration 0. table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 455 io_ext_time_cfg0_6 00_1006_1630 254/375 cs6 timing parameter configuration 0. io_ext_time_cfg0_7 00_1006_1638 254/375 cs7 timing parameter configuration 0. io_ext_time_cfg1_0 00_1006_1700 255/376 cs0 timing parameter configuration 1. io_ext_time_cfg1_1 00_1006_1708 255/376 cs1 timing parameter configuration 1. io_ext_time_cfg1_2 00_1006_1710 255/376 cs2 timing parameter configuration 1. io_ext_time_cfg1_3 00_1006_1718 255/376 cs3 timing parameter configuration 1. io_ext_time_cfg1_4 00_1006_1720 255/376 cs4 timing parameter configuration 1. io_ext_time_cfg1_5 00_1006_1728 255/376 cs5 timing parameter configuration 1. io_ext_time_cfg1_6 00_1006_1730 255/376 cs6 timing parameter configuration 1. io_ext_time_cfg1_7 00_1006_1738 255/376 cs7 timing parameter configuration 1. io_interrupt_status 00_1006_1a00 256/376 interrupt status for generic bus sources (read only, read clears). io_interrupt_data0 00_1006_1a10 257/377 data latched on generic interrupt assertion (read only). io_interrupt_data1 00_1006_1a18 258/377 data latched on generic interrupt assertion (read only). io_interrupt_data2 00_1006_1a20 259/377 data latched on generic interrupt assertion (read only). io_interrupt_data3 00_1006_1a28 260/377 data latched on generic interrupt assertion (read only). io_interrupt_addr0 00_1006_1a30 261/378 address latched on generic interrupt assertion (read only). io_interrupt_addr1 00_1006_1a40 262/378 address latched on generic interrupt assertion (read only). io_interrupt_parity 00_1006_1a50 263/378 parity latched on generic interrupt assertion (read only). pcmcia_cfg 00_1006_1a60 273/393 pcicma controller configuration. pcmcia_status 00_1006_1a70 274/394 pcmcia controller status (read only, read clears interrupt). gpio gpio_clr_edge 00_1006_1a80 276/398 write a 1 to clear the edge detector for that bit (write only). gpio_int_type 00_1006_1a88 277/398 select interrupt type for pairs of pins. gpio_input_invert 00_1006_1a90 279/398 set to invert the input. gpio_glitch 00_1006_1a98 280/399 set for 1ms glitch filter, clear for 60 ns. gpio_read 00_1006_1aa0 278/398 shows current value of signal after possible invert and glitch (read only). gpio_direction 00_1006_1aa8 281/399 gpio pin data direction. 1 for output, 0 for input. gpio_pin_clr 00_1006_1ab0 282/399 write 1 to set that bit to zero (write only). gpio_pin_set 00_1006_1ab8 283/399 write 1 to set that bit to one (write only). table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 456 section 16: reference document 1250_1125-um100-r output drive control io_drive_0 00_1006_1300 264/378 3.3v output drive strength and slew rate control registers. see section: ?drive strength control? on page 373 . io_drive_1 00_1006_1308 265/379 io_drive_2 00_1006_1310 266/380 io_drive_3 00_1006_1318 267/380 smbus smb_serial_xtra_0 00_1006_0000 294/416 smb port extra data register. smb_serial_xtra_1 00_1006_0008 294/416 smb port extra data register. smb_serial_freq_0 00_1006_0010 289/415 frequency for smb port. smb_serial_freq_1 00_1006_0018 289/415 frequency for smb port. smb_serial_status_0 00_1006_0020 292/416 smb port status (read clears finish interrupt). smb_serial_status_1 00_1006_0028 292/416 smb port status (read clears finish interrupt). smb_serial_cmd_0 00_1006_0030 290/415 smb port command. smb_serial_cmd_1 00_1006_0038 290/415 smb port command. smb_serial_start_0 00_1006_0040 296/417 smb port start register. smb_serial_start_1 00_1006_0048 296/417 smb port start register. smb_serial_data_0 00_1006_0050 293/416 smb port data register. smb_serial_data_1 00_1006_0058 293/416 smb port data register. smb_serial_control_0 00_1006_0060 291/415 smb port control register. smb_serial_control_1 00_1006_0068 291/415 smb port control register. smb_serial_pec_0 00_1006_0070 295/417 smb port pec register. smb_serial_pec_1 00_1006_0078 295/417 smb port pec register. scd: timers watchdog_timer_init_cnt_0 00_1002_0050 23/59 watchdog initial count. watchdog_timer_cnt_0 00_1002_0058 24/59 watchdog current count (read only). watchdog_timer_cfg_0 00_1002_0060 25/59 watchdog configuration (write clears interrupt). general_timer_init_cnt_0 00_1002_0070 26/60 general timer initial count. general_timer_init_cnt_1 00_1002_0078 26/60 general timer initial count. general_timer_cnt_0 00_1002_0080 27/60 general timer current count (read only). general_timer_cnt_1 00_1002_0088 27/60 general timer current count (read only). general_timer_cfg_0 00_1002_0090 28/60 general timer configuration and enable (write clears interrupt). general_timer_cfg_1 00_1002_0098 28/60 general timer configuration and enable (write clears interrupt). watchdog_timer_init_cnt_1 00_1002_0150 23/59 watchdog initial count. watchdog_timer_cnt_1 00_1002_0158 24/59 watchdog current count (read only). watchdog_timer_cfg_1 00_1002_0160 25/59 watchdog configuration (write clears interrupt). general_timer_init_cnt_2 00_1002_0170 26/60 general timer initial count. table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 457 general_timer_init_cnt_3 00_1002_0178 26/60 general timer initial count. general_timer_cnt_2 00_1002_0180 27/60 general timer current count (read only). general_timer_cnt_3 00_1002_0188 27/60 general timer current count (read only). general_timer_cfg_2 00_1002_0190 28/60 general timer configuration and enable (write clears interrupt). general_timer_cfg_3 00_1002_0198 28/60 general timer configuration and enable (write clears interrupt). zbbus_cycle_cnt 00_1003_0000 29/61 zbbus cycle count. zbbus_cycle_cp0 00_1002_0c00 30/61 zbbus cycle count compare register zero. zbbus_cycle_cp1 00_1002_0c08 30/61 zbbus cycle count compare register one. scd: system control system_revision 00_1002_0000 14/43 system id and revision (read only). system_cfg 00_1002_0008 15/43 system configuration register. system_scratch 00_1002_0c10 16/45 scratch register for software use system_manuf 00_1003_8000 14/43 read only. manufacturing information register. scd: address trap addr_trap_index 00_1002_00b0 40/68 index of interrupting trap (read only). addr_trap_reg 00_1002_00b8 42/68 address of interrupting trap (read only, read clears interrupt). addr_trap_reg_debug 00_1002_0460 41/68 address of interrupting trap (read only, no side effects). addr_trap_up_cfg_0 00_1002_0400 43/68 top of address trap range. addr_trap_up_cfg_1 00_1002_0408 43/68 top of address trap range. addr_trap_up_cfg_2 00_1002_0410 43/68 top of address trap range. addr_trap_up_cfg_3 00_1002_0418 43/68 top of address trap range. addr_trap_down_cfg_0 00_1002_0420 44/69 bottom of address trap range. addr_trap_down_cfg_1 00_1002_0428 44/69 bottom of address trap range. addr_trap_down_cfg_2 00_1002_0430 44/69 bottom of address trap range. addr_trap_down_cfg_3 00_1002_0438 44/69 bottom of address trap range. addr_trap_cfg_0 00_1002_0440 45/69 address trap configuration. addr_trap_cfg_1 00_1002_0448 45/69 address trap configuration. addr_trap_cfg_2 00_1002_0450 45/69 address trap configuration. addr_trap_cfg_3 00_1002_0458 45/69 address trap configuration. table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 458 section 16: reference document 1250_1125-um100-r scd: interrupt mapper interrupt_diag_0 00_1002_0010 21/52 force interrupt diagnostic register. interrupt_mask_0 00_1002_0028 21/52 interrupt mask. interrupt_source_status_0 00_1002_0040 21/52 status of system interrupt sources (read only). ldt_interrupt_0 00_1002_0018 21/52 status of hypertransport interrupt sources (read only). ldt_interrupt_clr_0 00_1002_0020 21/52 clear ldt_interrupt_0 by writing 1s to this location. interrupt_trace_0 00_1002_0038 21/52 set bits in this register to cause the corresponding interrupt to be passed to the trace trigger logic. ldt_interrupt_set 00_1002_0048 19/49 write hypertransport interrupt message to this address to raise a hypertransport interrupt (write only). mailbox_cpu_0 00_1002_00c0 17/46 status of mailbox (read only, has alias). alias_mailbox_cpu_0 00_1002_1xx0 17/46 alias of status of mailbox (has incomplete decode, so access from pci won't hang). (read only). mailbox_set_cpu_0 00_1002_00c8 17/46 set bits in mailbox_cpu_0 by writing 1s to this location (write only). alias_mailbox_set_cpu_0 00_1002_1xx8 17/46 set bits in mailbox_cpu_0 by writing 1s to this location (write only, has incomplete decode, so access from pci won't hang). mailbox_clr_cpu_0 00_1002_00d0 17/46 clear bits in mailbox_cpu_0 by writing 1s to this location (write only). interrupt_status0_0 00_1002_0100 21/52 status of mapped interrupt sources (read only). interrupt_status1_0 00_1002_0108 21/52 status of mapped interrupt sources (read only). interrupt_status2_0 00_1002_0110 21/52 status of mapped interrupt sources (read only). interrupt_status3_0 00_1002_0118 21/52 status of mapped interrupt sources (read only). interrupt_status4_0 00_1002_0120 21/52 status of mapped interrupt sources (read only). interrupt_status5_0 00_1002_0128 21/52 status of mapped interrupt sources (read only). interrupt_status6_0 00_1002_0130 21/52 status of mapped interrupt sources (read only). interrupt_status7_0 00_1002_0138 21/52 status of mapped interrupt sources (read only). interrupt_map0_0 00_1002_0200 18/47 source to irq map register. interrupt_map1_0 00_1002_0208 18/47 source to irq map register. interrupt_map2_0 00_1002_0210 18/47 source to irq map register. interrupt_map3_0 00_1002_0218 18/47 source to irq map register. interrupt_map4_0 00_1002_0220 18/47 source to irq map register. interrupt_map5_0 00_1002_0228 18/47 source to irq map register. interrupt_map6_0 00_1002_0230 18/47 source to irq map register. interrupt_map7_0 00_1002_0238 18/47 source to irq map register. interrupt_map8_0 00_1002_0240 18/47 source to irq map register. interrupt_map9_0 00_1002_0248 18/47 source to irq map register. interrupt_map10_0 00_1002_0250 18/47 source to irq map register. table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 459 interrupt_map11_0 00_1002_0258 18/47 source to irq map register. interrupt_map12_0 00_1002_0260 18/47 source to irq map register interrupt_map13_0 00_1002_0268 18/47 source to irq map register. interrupt_map14_0 00_1002_0270 18/47 source to irq map register. interrupt_map15_0 00_1002_0278 18/47 source to irq map register. interrupt_map16_0 00_1002_0280 18/47 source to irq map register. interrupt_map17_0 00_1002_0288 18/47 source to irq map register. interrupt_map18_0 00_1002_0290 18/47 source to irq map register. interrupt_map19_0 00_1002_0298 18/47 source to irq map register. interrupt_map20_0 00_1002_02a0 18/47 source to irq map register. interrupt_map21_0 00_1002_02a8 18/47 source to irq map register. interrupt_map22_0 00_1002_02b0 18/47 source to irq map register. interrupt_map23_0 00_1002_02b8 18/47 source to irq map register. interrupt_map24_0 00_1002_02c0 18/47 source to irq map register. interrupt_map25_0 00_1002_02c8 18/47 source to irq map register. interrupt_map26_0 00_1002_02d0 18/47 source to irq map register. interrupt_map27_0 00_1002_02d8 18/47 source to irq map register. interrupt_map28_0 00_1002_02e0 18/47 source to irq map register. interrupt_map29_0 00_1002_02e8 18/47 source to irq map register. interrupt_map30_0 00_1002_02f0 18/47 source to irq map register. interrupt_map31_0 00_1002_02f8 18/47 source to irq map register. interrupt_map32_0 00_1002_0300 18/47 source to irq map register. interrupt_map33_0 00_1002_0308 18/47 source to irq map register. interrupt_map34_0 00_1002_0310 18/47 source to irq map register. interrupt_map35_0 00_1002_0318 18/47 source to irq map register. interrupt_map36_0 00_1002_0320 18/47 source to irq map register. interrupt_map37_0 00_1002_0328 18/47 source to irq map register. interrupt_map38_0 00_1002_0330 18/47 source to irq map register. interrupt_map39_0 00_1002_0338 18/47 source to irq map register. interrupt_map40_0 00_1002_0340 18/47 source to irq map register. interrupt_map41_0 00_1002_0348 18/47 source to irq map register. interrupt_map42_0 00_1002_0350 18/47 source to irq map register. interrupt_map43_0 00_1002_0358 18/47 source to irq map register. interrupt_map44_0 00_1002_0360 18/47 source to irq map register. interrupt_map45_0 00_1002_0368 18/47 source to irq map register. interrupt_map46_0 00_1002_0370 18/47 source to irq map register. interrupt_map47_0 00_1002_0378 18/47 source to irq map register. table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 460 section 16: reference document 1250_1125-um100-r interrupt_map48_0 00_1002_0380 18/47 source to irq map register. interrupt_map49_0 00_1002_0388 18/47 source to irq map register. interrupt_map50_0 00_1002_0390 18/47 source to irq map register. interrupt_map51_0 00_1002_0398 18/47 source to irq map register. interrupt_map52_0 00_1002_03a0 18/47 source to irq map register. interrupt_map53_0 00_1002_03a8 18/47 source to irq map register. interrupt_map54_0 00_1002_03b0 18/47 source to irq map register. interrupt_map55_0 00_1002_03b8 18/47 source to irq map register. interrupt_map56_0 00_1002_03c0 18/47 source to irq map register. interrupt_map57_0 00_1002_03c8 18/47 source to irq map register. interrupt_map58_0 00_1002_03d0 18/47 source to irq map register. interrupt_map59_0 00_1002_03d8 18/47 source to irq map register. interrupt_map60_0 00_1002_03e0 18/47 source to irq map register. interrupt_map61_0 00_1002_03e8 18/47 source to irq map register. interrupt_map62_0 00_1002_03f0 18/47 source to irq map register. interrupt_map63_0 00_1002_03f8 18/47 source to irq map register. int_mapper_1 00_1002_2000 2000-23f8 registers for cpu 1 interrupt mapper (+2000 from cpu 0). scd: performance counters perf_cnt_cfg 00_1002_04c0 31/61 performance counter control. perf_cnt_0 00_1002_04d0 32/62 performance counter. perf_cnt_1 00_1002_04d8 32/62 performance counter. perf_cnt_2 00_1002_04e0 32/62 performance counter. perf_cnt_3 00_1002_04e8 32/62 performance counter. scd: bus watcher bus_err_status 00_1002_0880 35/65 bus error status (read only). bus_err_status_debug 00_1002_08d0 36/65 bus error status (read only). bus_err_data_0 00_1002_08a0 37/65 data or address/control information latched on bus error (read only). bus_err_data_1 00_1002_08a8 37/65 data or address/control information latched on bus error (read only). bus_err_data_2 00_1002_08b0 37/65 data or address/control information latched on bus error (read only). bus_err_data_3 00_1002_08b8 37/65 data or address/control information latched on bus error (read only). bus_l2_errors 00_1002_08c0 38/66 count of l2 ecc errors (4 8-bit counters). bus_mem_io_errors 00_1002_08c8 39/66 count of memory ecc errors and i/o errors (3 8-bit counters). table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 461 scd: debug controller jtag_space 00_1000_0000 jtag serviced debug space 1000_0000-1001_ffff . scd: trace buffer trace_cfg 00_1002_0a00 48/76 trace configuration. trace_read 00_1002_0a08 50/79 trace buffer read register (read only). trace_event_0 00_1002_0a20 46/72 trace event selector. trace_event_1 00_1002_0a28 46/72 trace event selector. trace_event_2 00_1002_0a30 46/72 trace event selector. trace_event_3 00_1002_0a38 46/72 trace event selector. trace_sequence_0 00_1002_0a40 47/74 trace sequence and action. trace_sequence_1 00_1002_0a48 47/74 trace sequence and action. trace_sequence_2 00_1002_0a50 47/74 trace sequence and action. trace_sequence_3 00_1002_0a58 47/74 trace sequence and action. trace_event_4 00_1002_0a60 46/72 trace event selector. trace_event_5 00_1002_0a68 46/72 trace event selector. trace_event_6 00_1002_0a70 46/72 trace event selector. trace_event_7 00_1002_0a78 46/72 trace event selector. trace_sequence_4 00_1002_0a80 47/74 trace sequence and action. trace_sequence_5 00_1002_0a88 47/74 trace sequence and action. trace_sequence_6 00_1002_0a90 47/74 trace sequence and action. trace_sequence_7 00_1002_0a98 47/74 trace sequence and action. scd: data mover dm_dscr_base_0 00_1002_0b00 114/184 data mover channel 0 ring base address (read clears some bits). dm_dscr_count_0 00_1002_0b08 116/185 data mover channel 0 descriptor count. dm_dscr_addr_0 00_1002_0b10 117/185 data mover channel 0 current address (read only). dm_debug_dscr_base_0 00_1002_0b18 115/184 debug alias for channel 0 ring base address (read only, no side effects). dm_partial_0 00_1002_0ba0 120/186 crc/checksum partial result register. dm_dscr_base_1 00_1002_0b20 114/184 data mover channel 1 ring base address (read clears some bits). dm_dscr_count_1 00_1002_0b28 116/185 data mover channel 1 descriptor count. dm_dscr_addr_1 00_1002_0b30 117/185 data mover channel 1 current address. (read only) dm_debug_dscr_base_1 00_1002_0b38 115/184 debug alias for channel 1 ring base address (read only, no side effects). dm_partial_1 00_1002_0ba8 120/186 crc/checksum partial result register. dm_dscr_base_2 00_1002_0b40 114/184 data mover channel 2 ring base address (read clears some bits). dm_dscr_count_2 00_1002_0b48 116/185 data mover channel 2 descriptor count. table 311: internal register addresses by function (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 462 section 16: reference document 1250_1125-um100-r dm_dscr_addr_2 00_1002_0b50 117/185 data mover channel 2 current address (read only). dm_debug_dscr_base_2 00_1002_0b58 115/184 debug alias for channel 2 ring base address (read only, no side effects). dm_partial_2 00_1002_0bb0 120/186 crc/checksum partial result register. dm_dscr_base_3 00_1002_0b60 114/184 data mover channel 3 ring base address (read clears some bits). dm_dscr_count_3 00_1002_0b68 116/185 data mover channel 3 descriptor count. dm_dscr_addr_3 00_1002_0b70 117/185 data mover channel 3 current address (read only). dm_debug_dscr_base_3 00_1002_0b78 115/184 debug alias for channel 3 ring base address (read only, no side effects). dm_partial_3 00_1002_0bb8 120/186 crc/checksum partial result register. crc_def_0 00_1002_0b80 118/185 crc definition register. ctcp_def_0 00_1002_0b88 119/186 crc and checksum definition register. crc_def_1 00_1002_0b90 118/185 crc definition register. ctcp_def_1 00_1002_0b98 119/186 crc and checksum definition register. table 311: internal register addresses by function (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 463 bcm1250/BCM1125/h i nternal r egisters o rdered by a ddress table 312: internal registers ordered by address name address table/ page description jtag_space 00_1000_0000 jtag serviced debug space 1000_0000-1001_ffff . system_revision 00_1002_0000 14/43 system id and revision (read only). system_cfg 00_1002_0008 15/43 system configuration register. interrupt_diag_0 00_1002_0010 21/52 force interrupt diagnostic register. ldt_interrupt_0 00_1002_0018 21/52 status of hypertransport interrupt sources (read only). ldt_interrupt_clr_0 00_1002_0020 21/52 clear ldt_interrupt_0 by writing 1s to this location. interrupt_mask_0 00_1002_0028 21/52 interrupt mask. interrupt_trace_0 00_1002_0038 21/52 set bits in this register to cause the corresponding interrupt to be passed to the trace trigger logic. interrupt_source_status_0 00_1002_0040 21/52 status of system interrupt sources (read only). ldt_interrupt_set 00_1002_0048 19/49 write hypertransport interrupt message to this address to raise a hypertransport interrupt (write only). watchdog_timer_init_cnt_0 00_1002_0050 23/59 watchdog initial count. watchdog_timer_cnt_0 00_1002_0058 24/59 watchdog current count (read only). watchdog_timer_cfg_0 00_1002_0060 25/59 watchdog configuration (write clears interrupt). general_timer_init_cnt_0 00_1002_0070 26/60 general timer initial count. general_timer_init_cnt_1 00_1002_0078 26/60 general timer initial count. general_timer_cnt_0 00_1002_0080 27/60 general timer current count (read only). general_timer_cnt_1 00_1002_0088 27/60 general timer current count (read only). general_timer_cfg_0 00_1002_0090 28/60 general timer configuration and enable (write clears interrupt). general_timer_cfg_1 00_1002_0098 28/60 general timer configuration and enable (write clears interrupt). addr_trap_index 00_1002_00b0 40/68 index of interrupting trap (read only). addr_trap_reg 00_1002_00b8 42/68 address of interrupting trap (read only, read clears interrupt). mailbox_cpu_0 00_1002_00c0 17/46 status of mailbox (read only, has alias). mailbox_set_cpu_0 00_1002_00c8 17/46 set bits in mailbox_cpu_0 by writing 1s to this location (write only). mailbox_clr_cpu_0 00_1002_00d0 17/46 clear bits in mailbox_cpu_0 by writing 1s to this location (write only). interrupt_status0_0 00_1002_0100 21/52 status of mapped interrupt sources (read only). interrupt_status1_0 00_1002_0108 21/52 status of mapped interrupt sources (read only). interrupt_status2_0 00_1002_0110 21/52 status of mapped interrupt sources (read only). interrupt_status3_0 00_1002_0118 21/52 status of mapped interrupt sources (read only). interrupt_status4_0 00_1002_0120 21/52 status of mapped interrupt sources (read only). bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 464 section 16: reference document 1250_1125-um100-r interrupt_status5_0 00_1002_0128 21/52 status of mapped interrupt sources (read only). interrupt_status6_0 00_1002_0130 21/52 status of mapped interrupt sources (read only). interrupt_status7_0 00_1002_0138 21/52 status of mapped interrupt sources (read only). watchdog_timer_init_cnt_1 00_1002_0150 23/59 watchdog initial count. watchdog_timer_cnt_1 00_1002_0158 24/59 watchdog current count (read only). watchdog_timer_cfg_1 00_1002_0160 25/59 watchdog configuration (write clears interrupt). general_timer_init_cnt_2 00_1002_0170 26/60 general timer initial count. general_timer_init_cnt_3 00_1002_0178 26/60 general timer initial count. general_timer_cnt_2 00_1002_0180 27/60 general timer current count (read only). general_timer_cnt_3 00_1002_0188 27/60 general timer current count (read only). general_timer_cfg_2 00_1002_0190 28/60 general timer configuration and enable (write clears interrupt). general_timer_cfg_3 00_1002_0198 28/60 general timer configuration and enable (write clears interrupt). interrupt_map0_0 00_1002_0200 18/47 source to irq map register. interrupt_map1_0 00_1002_0208 18/47 source to irq map register. interrupt_map2_0 00_1002_0210 18/47 source to irq map register. interrupt_map3_0 00_1002_0218 18/47 source to irq map register. interrupt_map4_0 00_1002_0220 18/47 source to irq map register. interrupt_map5_0 00_1002_0228 18/47 source to irq map register. interrupt_map6_0 00_1002_0230 18/47 source to irq map register. interrupt_map7_0 00_1002_0238 18/47 source to irq map register. interrupt_map8_0 00_1002_0240 18/47 source to irq map register. interrupt_map9_0 00_1002_0248 18/47 source to irq map register. interrupt_map10_0 00_1002_0250 18/47 source to irq map register. interrupt_map11_0 00_1002_0258 18/47 source to irq map register. interrupt_map12_0 00_1002_0260 18/47 source to irq map register interrupt_map13_0 00_1002_0268 18/47 source to irq map register. interrupt_map14_0 00_1002_0270 18/47 source to irq map register. interrupt_map15_0 00_1002_0278 18/47 source to irq map register. interrupt_map16_0 00_1002_0280 18/47 source to irq map register. interrupt_map17_0 00_1002_0288 18/47 source to irq map register. interrupt_map18_0 00_1002_0290 18/47 source to irq map register. interrupt_map19_0 00_1002_0298 18/47 source to irq map register. interrupt_map20_0 00_1002_02a0 18/47 source to irq map register. interrupt_map21_0 00_1002_02a8 18/47 source to irq map register. interrupt_map22_0 00_1002_02b0 18/47 source to irq map register. interrupt_map23_0 00_1002_02b8 18/47 source to irq map register. table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 465 interrupt_map24_0 00_1002_02c0 18/47 source to irq map register. interrupt_map25_0 00_1002_02c8 18/47 source to irq map register. interrupt_map26_0 00_1002_02d0 18/47 source to irq map register. interrupt_map27_0 00_1002_02d8 18/47 source to irq map register. interrupt_map28_0 00_1002_02e0 18/47 source to irq map register. interrupt_map29_0 00_1002_02e8 18/47 source to irq map register. interrupt_map30_0 00_1002_02f0 18/47 source to irq map register. interrupt_map31_0 00_1002_02f8 18/47 source to irq map register. interrupt_map32_0 00_1002_0300 18/47 source to irq map register. interrupt_map33_0 00_1002_0308 18/47 source to irq map register. interrupt_map34_0 00_1002_0310 18/47 source to irq map register. interrupt_map35_0 00_1002_0318 18/47 source to irq map register. interrupt_map36_0 00_1002_0320 18/47 source to irq map register. interrupt_map37_0 00_1002_0328 18/47 source to irq map register. interrupt_map38_0 00_1002_0330 18/47 source to irq map register. interrupt_map39_0 00_1002_0338 18/47 source to irq map register. interrupt_map40_0 00_1002_0340 18/47 source to irq map register. interrupt_map41_0 00_1002_0348 18/47 source to irq map register. interrupt_map42_0 00_1002_0350 18/47 source to irq map register. interrupt_map43_0 00_1002_0358 18/47 source to irq map register. interrupt_map44_0 00_1002_0360 18/47 source to irq map register. interrupt_map45_0 00_1002_0368 18/47 source to irq map register. interrupt_map46_0 00_1002_0370 18/47 source to irq map register. interrupt_map47_0 00_1002_0378 18/47 source to irq map register. interrupt_map48_0 00_1002_0380 18/47 source to irq map register. interrupt_map49_0 00_1002_0388 18/47 source to irq map register. interrupt_map50_0 00_1002_0390 18/47 source to irq map register. interrupt_map51_0 00_1002_0398 18/47 source to irq map register. interrupt_map52_0 00_1002_03a0 18/47 source to irq map register. interrupt_map53_0 00_1002_03a8 18/47 source to irq map register. interrupt_map54_0 00_1002_03b0 18/47 source to irq map register. interrupt_map55_0 00_1002_03b8 18/47 source to irq map register. interrupt_map56_0 00_1002_03c0 18/47 source to irq map register. interrupt_map57_0 00_1002_03c8 18/47 source to irq map register. interrupt_map58_0 00_1002_03d0 18/47 source to irq map register. interrupt_map59_0 00_1002_03d8 18/47 source to irq map register. interrupt_map60_0 00_1002_03e0 18/47 source to irq map register. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 466 section 16: reference document 1250_1125-um100-r interrupt_map61_0 00_1002_03e8 18/47 source to irq map register. interrupt_map62_0 00_1002_03f0 18/47 source to irq map register. interrupt_map63_0 00_1002_03f8 18/47 source to irq map register. addr_trap_up_cfg_0 00_1002_0400 43/68 top of address trap range. addr_trap_up_cfg_1 00_1002_0408 43/68 top of address trap range. addr_trap_up_cfg_2 00_1002_0410 43/68 top of address trap range. addr_trap_up_cfg_3 00_1002_0418 43/68 top of address trap range. addr_trap_down_cfg_0 00_1002_0420 44/69 bottom of address trap range. addr_trap_down_cfg_1 00_1002_0428 44/69 bottom of address trap range. addr_trap_down_cfg_2 00_1002_0430 44/69 bottom of address trap range. addr_trap_down_cfg_3 00_1002_0438 44/69 bottom of address trap range. addr_trap_cfg_0 00_1002_0440 45/69 address trap configuration. addr_trap_cfg_1 00_1002_0448 45/69 address trap configuration. addr_trap_cfg_2 00_1002_0450 45/69 address trap configuration. addr_trap_cfg_3 00_1002_0458 45/69 address trap configuration. addr_trap_reg_debug 00_1002_0460 41/68 address of interrupting trap (read only, no side effects). perf_cnt_cfg 00_1002_04c0 31/61 performance counter control. perf_cnt_0 00_1002_04d0 32/62 performance counter. perf_cnt_1 00_1002_04d8 32/62 performance counter. perf_cnt_2 00_1002_04e0 32/62 performance counter. perf_cnt_3 00_1002_04e8 32/62 performance counter. bus_err_status 00_1002_0880 35/65 bus error status (read only). bus_err_data_0 00_1002_08a0 37/65 data or address/control information latched on bus error (read only). bus_err_data_1 00_1002_08a8 37/65 data or address/control information latched on bus error (read only). bus_err_data_2 00_1002_08b0 37/65 data or address/control information latched on bus error (read only). bus_err_data_3 00_1002_08b8 37/65 data or address/control information latched on bus error (read only). bus_l2_errors 00_1002_08c0 38/66 count of l2 ecc errors (4 8-bit counters). bus_mem_io_errors 00_1002_08c8 39/66 count of memory ecc errors and i/o errors (3 8-bit counters). bus_err_status_debug 00_1002_08d0 36/65 bus error status (read only). trace_cfg 00_1002_0a00 48/76 trace configuration. trace_read 00_1002_0a08 50/79 trace buffer read register (read only). trace_event_0 00_1002_0a20 46/72 trace event selector. trace_event_1 00_1002_0a28 46/72 trace event selector. trace_event_2 00_1002_0a30 46/72 trace event selector. table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 467 trace_event_3 00_1002_0a38 46/72 trace event selector. trace_sequence_0 00_1002_0a40 47/74 trace sequence and action. trace_sequence_1 00_1002_0a48 47/74 trace sequence and action. trace_sequence_2 00_1002_0a50 47/74 trace sequence and action. trace_sequence_3 00_1002_0a58 47/74 trace sequence and action. trace_event_4 00_1002_0a60 46/72 trace event selector. trace_event_5 00_1002_0a68 46/72 trace event selector. trace_event_6 00_1002_0a70 46/72 trace event selector. trace_event_7 00_1002_0a78 46/72 trace event selector. trace_sequence_4 00_1002_0a80 47/74 trace sequence and action. trace_sequence_5 00_1002_0a88 47/74 trace sequence and action. trace_sequence_6 00_1002_0a90 47/74 trace sequence and action. trace_sequence_7 00_1002_0a98 47/74 trace sequence and action. dm_dscr_base_0 00_1002_0b00 114/184 data mover channel 0 ring base address (read clears some bits). dm_dscr_count_0 00_1002_0b08 116/185 data mover channel 0 descriptor count. dm_dscr_addr_0 00_1002_0b10 117/185 data mover channel 0 current address (read only). dm_debug_dscr_base_0 00_1002_0b18 115/184 debug alias for channel 0 ring base address (read only, no side effects). dm_dscr_base_1 00_1002_0b20 114/184 data mover channel 1 ring base address (read clears some bits). dm_dscr_count_1 00_1002_0b28 116/185 data mover channel 1 descriptor count. dm_dscr_addr_1 00_1002_0b30 117/185 data mover channel 1 current address. (read only) dm_debug_dscr_base_1 00_1002_0b38 115/184 debug alias for channel 1 ring base address (read only, no side effects). dm_dscr_base_2 00_1002_0b40 114/184 data mover channel 2 ring base address (read clears some bits). dm_dscr_count_2 00_1002_0b48 116/185 data mover channel 2 descriptor count. dm_dscr_addr_2 00_1002_0b50 117/185 data mover channel 2 current address (read only). dm_debug_dscr_base_2 00_1002_0b58 115/184 debug alias for channel 2 ring base address (read only, no side effects). dm_dscr_base_3 00_1002_0b60 114/184 data mover channel 3 ring base address (read clears some bits). dm_dscr_count_3 00_1002_0b68 116/185 data mover channel 3 descriptor count. dm_dscr_addr_3 00_1002_0b70 117/185 data mover channel 3 current address (read only). dm_debug_dscr_base_3 00_1002_0b78 115/184 debug alias for channel 3 ring base address (read only, no side effects). crc_def_0 00_1002_0b80 118/185 crc definition register. ctcp_def_0 00_1002_0b88 119/186 crc and checksum definition register. crc_def_1 00_1002_0b90 118/185 crc definition register. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 468 section 16: reference document 1250_1125-um100-r ctcp_def_1 00_1002_0b98 119/186 crc and checksum definition register. dm_partial_0 00_1002_0ba0 120/186 crc/checksum partial result register. dm_partial_1 00_1002_0ba8 120/186 crc/checksum partial result register. dm_partial_2 00_1002_0bb0 120/186 crc/checksum partial result register. dm_partial_3 00_1002_0bb8 120/186 crc/checksum partial result register. zbbus_cycle_cp0 00_1002_0c00 30/61 zbbus cycle count compare register zero. zbbus_cycle_cp1 00_1002_0c08 30/61 zbbus cycle count compare register one. system_scratch 00_1002_0c10 16/45 scratch register for software use alias_mailbox_cpu_0 00_1002_1xx0 17/46 alias of status of mailbox (has incomplete decode, so access from pci won't hang). (read only). alias_mailbox_set_cpu_0 00_1002_1xx8 17/46 set bits in mailbox_cpu_0 by writing 1s to this location (write only, has incomplete decode, so access from pci won't hang). int_mapper_1 00_1002_2000 2000-23f8 registers for cpu 1 interrupt mapper (+2000 from cpu 0). zbbus_cycle_cnt 00_1003_0000 29/61 zbbus cycle count. system_manuf 00_1003_8000 14/43 read only. manufacturing information register. l2_read_address 00_1004_0018 56/100 read only. last address/tag in a read (for testing) l2_ecc_address 00_1004_0038 56/100 read only. last address with ecc error (correctable or not). l2_misc_value 00_1004_0058 57/100 read only. periph_rev3 and later. value of l2 hidden registers. l2_way_disable 00_1004_1x00 /91 accesses made to this range of addresses will write the value x to l2_wayen[3:0] register. if l2_wayen[i] is clear way i is removed from the l2 replacement algorithm. see section: ?using the l2 cache as memory? on page 91 l2_cache_disable 00_1004_2x00 /94 accesses made to this range of addresses will write the value x to l2_cache_disable[3:0] register. see section: ?reduced cache size? on page 94 . l2_misc_config 00_1004_3x00 /99 accesses made to this range of addresses will write the value x to l2_misc_config[3:0] register. see section: ?cache configuration register? on page 99 . mc_config_0 00_1005_1100 72/135 channel 0 attributes. mc_dramcmd_0 00_1005_1120 75/139 channel 0 sdram command. mc_drammode_0 00_1005_1140 76/139 channel 0 sdram mode. mc_timing1_0 00_1005_1160 77/140 channel 0 sdram timing 1. mc_timing2_0 00_1005_1180 78/141 channel 0 sdram timing 2. mc_cs_start_0 00_1005_11a0 79/141 channel 0 cs[3:0] start address. mc_cs_end_0 00_1005_11c0 80/141 channel 0 cs[3:0] end+1 address. mc_interleave_0 00_1005_11e0 81/142 channel 0 interleaved cs position. mc_cs0_row_0 00_1005_1200 82/142 channel 0 cs0 row address bits. table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 469 mc_cs0_col_0 00_1005_1220 83/142 channel 0 cs0 column address bits. mc_cs0_ba_0 00_1005_1240 84/143 channel 0 cs0 bank select. mc_cs1_row_0 00_1005_1260 82/142 channel 0 cs1 row address bits. mc_cs1_col_0 00_1005_1280 83/142 channel 0 cs1 column address bits. mc_cs1_ba_0 00_1005_12a0 84/143 channel 0 cs1 dram bank select. mc_cs2_row_0 00_1005_12c0 82/142 channel 0 cs2 row address bits. mc_cs2_col_0 00_1005_12e0 83/142 channel 0 cs2 column address bits. mc_cs2_ba_0 00_1005_1300 84/143 channel 0 cs2 dram bank select. mc_cs3_row_0 00_1005_1320 82/142 channel 0 cs3 row address bits. mc_cs3_col_0 00_1005_1340 83/142 channel 0 cs3 column address bits. mc_cs3_ba_0 00_1005_1360 83/142 channel 0 cs3 dram bank select. mc_cs_attr_0 00_1005_1380 85/143 channel 0 cs[3:0]attribute. mc_test_data_0 00_1005_1400 86/144 channel 0 ecc error set data bits. mc_test_ecc_0 00_1005_1420 87/144 channel 0 ecc error set ecc bits. mc_clock_cfg_0 00_1005_1500 74/138 channel 0 memory clock ratio. mc__1 00_1005_2000 ... 00_1005_2600 see _0 above memory controller channel 1 configuration (at memory controler 0 + 1000). smb_serial_xtra_0 00_1006_0000 294/416 smb port extra data register. smb_serial_xtra_1 00_1006_0008 294/416 smb port extra data register. smb_serial_freq_0 00_1006_0010 289/415 frequency for smb port. smb_serial_freq_1 00_1006_0018 289/415 frequency for smb port. smb_serial_status_0 00_1006_0020 292/416 smb port status (read clears finish interrupt). smb_serial_status_1 00_1006_0028 292/416 smb port status (read clears finish interrupt). smb_serial_cmd_0 00_1006_0030 290/415 smb port command. smb_serial_cmd_1 00_1006_0038 290/415 smb port command. smb_serial_start_0 00_1006_0040 296/417 smb port start register. smb_serial_start_1 00_1006_0048 296/417 smb port start register. smb_serial_data_0 00_1006_0050 293/416 smb port data register. smb_serial_data_1 00_1006_0058 293/416 smb port data register. smb_serial_control_0 00_1006_0060 291/415 smb port control register. smb_serial_control_1 00_1006_0068 291/415 smb port control register. smb_serial_pec_0 00_1006_0070 295/417 smb port pec register. smb_serial_pec_1 00_1006_0078 295/417 smb port pec register. duart_mode_reg_1a 00_1006_0100 197/326 mode register 1 port a mr1a. duart_mode_reg_2a 00_1006_0110 198/326 mode register 2 port a mr2a. duart_status_a 00_1006_0120 200/327 status register port a (read only). duart_clk_sel_a 00_1006_0130 201/328 clock select register port a. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 470 section 16: reference document 1250_1125-um100-r duart_full_ctl_a 00_1006_0140 202/328 full control port a. duart_cmd_a 00_1006_0150 199/327 command register port a. duart_rx_hold_reg_a 00_1006_0160 203/328 rx holding register port a (read only, read pops character from fifo). duart_tx_hold_reg_a 00_1006_0170 204/329 tx holding register port a (write only). duart_opcr_a 00_1006_0180 211/331 output port control register alias that only alters port a bits. duart_aux_ctrl_a 00_1006_0190 213/331 aux control register alias that only alters port a bits. duart_mode_reg_1b 00_1006_0200 197/326 mode register 1 port b. duart_mode_reg_2b 00_1006_0210 198/326 mode register 2 port b. duart_status_b 00_1006_0220 200/327 status register port b (read only). duart_clk_sel_b 00_1006_0230 201/328 clock select register port b. duart_full_ctl_b 00_1006_0240 202/328 full control port b. duart_cmd_b 00_1006_0250 199/327 command register port b. duart_rx_hold_reg_b 00_1006_0260 203/328 rx holding register port b (read only, read pops character from fifo). duart_tx_hold_reg_b 00_1006_0270 204/329 tx holding register port b (write only). duart_opcr_b 00_1006_0280 211/331 output port control register alias that only alters port b bits. duart_aux_ctrl_b 00_1006_0290 213/331 aux control register alias that only alters port b bits. duart_inport_chng 00_1006_0300 206/329 input port change register (read only, read clears). duart_aux_cntrl 00_1006_0310 212/331 aux control register. duart_isr_a 00_1006_0320 215/332 interrupt status register port a (read only). duart_imr_a 00_1006_0330 218/333 interrupt mask register port a. duart_isr_b 00_1006_0340 216/332 interrupt status register port b (read only). duart_imr_b 00_1006_0350 219/333 interrupt mask register port b. duart_out_port 00_1006_0360 222/334 output port register (write only). duart_opcr 00_1006_0370 210/330 output port control. duart_in_port 00_1006_0380 205/329 input port state (read only). duart_isr 00_1006_0390 214/332 full interrupt status (read only). duart_imr 00_1006_03a0 217/333 full interrupt mask. duart_set_opr 00_1006_03b0 220/334 output port register bit set (write only). duart_clear_opr 00_1006_03c0 221/334 output port register bit clear (write only). duart_inport_chng_a 00_1006_03d0 208/330 input port change register for channel a (read only, read clears channel a change state) duart_inport_chng_b 00_1006_03e0 209/330 input port change register for channel b (read only, read clears channel b change state) duart_inport_chng_debug 00_1006_03f0 207/330 alias of input port change register with no read side effects. (read only) dma_config0_ser_0_rx 00_1006_0400 91/163 receive dma control register. dma_config1_ser_0_rx 00_1006_0408 92/164 receive dma control register. table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 471 dma_dscr_base_ser_0_rx 00_1006_0410 93/166 receive dma descriptor base address. dma_dscr_cnt_ser_0_rx 00_1006_0418 95/166 receive dma descriptor count . dma_cur_dscr_a_ser_0_rx 00_1006_0420 96/167 receive dma current descriptor a (read only). dma_cur_dscr_b_ser_0_rx 00_1006_0428 97/167 receive dma current descriptor b (read only). dma_cur_daddr_ser_0_rx 00_1006_0430 98/167 receive dma current descriptor address (read only). dma_config0_ser_0_tx 00_1006_0480 91/163 transmit dma control register. dma_config1_ser_0_tx 00_1006_0488 92/164 transmit dma control register. dma_dscr_base_ser_0_tx 00_1006_0490 93/166 transmit dma descriptor base address. dma_dscr_cnt_ser_0_tx 00_1006_0498 95/166 transmit dma descriptor count. dma_cur_dscr_a_ser_0_tx 00_1006_04a0 96/167 transmit dma current descriptor a (read only). dma_cur_dscr_b_ser_0_tx 00_1006_04a8 97/167 transmit dma current descriptor b (read only). dma_cur_daddr_ser_0_tx 00_1006_04b0 98/167 transmit dma current descriptor address (read only). ser_mode_0 00_1006_0500 231/353 mode select. ser_minfrm_sz_0 00_1006_0508 237/355 min frame size. ser_maxfrm_sz_0 00_1006_0510 238/356 max frame size. ser_addr_mask_0 00_1006_0518 243/358 address mask. ser_usr0_addr_0 00_1006_0520 244/358 match address 0. ser_usr1_addr_0 00_1006_0528 244/358 match address 1. ser_usr2_addr_0 00_1006_0530 244/358 match address 2. ser_usr3_addr_0 00_1006_0538 244/358 match address 3. ser_cmd_0 00_1006_0540 233/354 command ser_tx_rd_thrsh_0 00_1006_0560 235/355 transmit fifo read threshold. ser_tx_wr_thrsh_0 00_1006_0568 234/355 transmit fifo write threshold. ser_rx_rd_thrsh_0 00_1006_0570 236/355 receive fifo read threshold. ser_line_mode_0 00_1006_0578 232/353 line interface configuration register. ser_dma_enable_0 00_1006_0580 239/356 dma channel enable register. ser_status_0 00_1006_0588 240/356 serial interface and dma status (read only, read clears). ser_int_mask_0 00_1006_0590 242/357 interrupt mask. dma_asic_addr_ser_0 00_1006_0598 94/166 asic mode address. ser_debug_status_0 00_1006_05a8 241/357 serial interface and dma status (read only, no side effects). ser_tx_byte_lo_0 00_1006_05c0 246/359 serial interface transmit byte count (low 16 bits). ser_tx_byte_hi_0 00_1006_05c8 246/359 serial interface transmit byte count (high 16 bits). ser_rx_byte_lo_0 00_1006_05d0 246/359 serial interface receive byte count (low 16 bits). ser_rx_byte_hi_0 00_1006_05d8 246/359 serial interface receive byte count (high 16 bits). ser_tx_underrun_0 00_1006_05e0 246/359 serial interface transmit underrun count. ser_rx_overflow_0 00_1006_05e8 246/359 serial interface receive overflow count. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 472 section 16: reference document 1250_1125-um100-r ser_rx_errors_0 00_1006_05f0 246/359 serial interface receive error packet count. ser_rx_badaddr_0 00_1006_05f8 246/359 serial interface receive address mismatch count. ser_rx_table0_0 00_1006_0600 245/358 sequence table. ser_rx_table1_0 00_1006_0608 245/358 sequence table. ser_rx_table2_0 00_1006_0610 245/358 sequence table. ser_rx_table3_0 00_1006_0618 245/358 sequence table. ser_rx_table4_0 00_1006_0620 245/358 sequence table. ser_rx_table5_0 00_1006_0628 245/358 sequence table. ser_rx_table6_0 00_1006_0630 245/358 sequence table. ser_rx_table7_0 00_1006_0638 245/358 sequence table. ser_rx_table8_0 00_1006_0640 245/358 sequence table. ser_rx_table9_0 00_1006_0648 245/358 sequence table. ser_rx_table10_0 00_1006_0650 245/358 sequence table. ser_rx_table11_0 00_1006_0658 245/358 sequence table. ser_rx_table12_0 00_1006_0660 245/358 sequence table. ser_rx_table13_0 00_1006_0668 245/358 sequence table. ser_rx_table14_0 00_1006_0670 245/358 sequence table. ser_rx_table15_0 00_1006_0678 245/358 sequence table. ser_tx_table0_0 00_1006_0700 245/358 sequence table. ser_tx_table1_0 00_1006_0708 245/358 sequence table. ser_tx_table2_0 00_1006_0710 245/358 sequence table. ser_tx_table3_0 00_1006_0718 245/358 sequence table. ser_tx_table4_0 00_1006_0720 245/358 sequence table. ser_tx_table5_0 00_1006_0728 245/358 sequence table. ser_tx_table6_0 00_1006_0730 245/358 sequence table. ser_tx_table7_0 00_1006_0738 245/358 sequence table. ser_tx_table8_0 00_1006_0740 245/358 sequence table. ser_tx_table9_0 00_1006_0748 245/358 sequence table. ser_tx_table10_0 00_1006_0750 245/358 sequence table. ser_tx_table11_0 00_1006_0758 245/358 sequence table. ser_tx_table12_0 00_1006_0760 245/358 sequence table. ser_tx_table13_0 00_1006_0768 245/358 sequence table. ser_tx_table14_0 00_1006_0770 245/358 sequence table. ser_tx_table15_0 00_1006_0778 245/358 sequence table. dma_config0_ser_1_rx 00_1006_0800 91/163 receive dma control register. dma_config1_ser_1_rx 00_1006_0808 92/164 receive dma control register. dma_dscr_base_ser_1_rx 00_1006_0810 93/166 receive dma descriptor base address. table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 473 dma_dscr_count_ser_1_rx 00_1006_0818 95/166 receive dma descriptor count. dma_cur_dscr_a_ser_1_rx 00_1006_0820 96/167 receive dma current descriptor a (read only). dma_cur_dscr_b_ser_1_rx 00_1006_0828 97/167 receive dma current descriptor b (read only). dma_cur_daddr_ser_1_rx 00_1006_0830 98/167 receive dma current descriptor address (read only). dma_config0_ser_1_tx 00_1006_0880 91/163 transmit dma control register. dma_config1_ser_1_tx 00_1006_0888 92/164 transmit dma control register. dma_dscr_base_ser_1_tx 00_1006_0890 93/166 transmit dma descriptor base address. dma_dscr_count_ser_1_tx 00_1006_0898 95/166 transmit dma descriptor count. dma_cur_dscr_a_ser_1_tx 00_1006_08a0 96/167 transmit dma current descriptor a (read only). dma_cur_dscr_b_ser_1_tx 00_1006_08a8 97/167 transmit dma current descriptor b (read only). dma_cur_daddr_ser_1_tx 00_1006_08b0 98/167 transmit dma current descriptor address (read only). ser_mode_1 00_1006_0900 231/353 mode select. ser_minfrm_sz_1 00_1006_0908 237/355 min frame size. ser_maxfrm_sz_1 00_1006_0910 238/356 max frame size. ser_addr_mask_1 00_1006_0918 243/358 address mask. ser_usr0_addr_1 00_1006_0920 244/358 match address 0. ser_usr1_addr_1 00_1006_0928 244/358 match address 1. ser_usr2_addr_1 00_1006_0930 244/358 match address 2. ser_usr3_addr_1 00_1006_0938 244/358 match address 3. ser_cmd_1 00_1006_0940 233/354 command ser_tx_rd_thrsh_1 00_1006_0960 235/355 transmit fifo read threshold. ser_tx_wr_thrsh_1 00_1006_0968 234/355 transmit fifo write threshold. ser_rx_rd_thrsh_1 00_1006_0970 236/355 receive fifo read threshold. ser_line mode_1 00_1006_0978 232/353 line interface configuration register. ser_dma_enable_1 00_1006_0980 239/356 dma channel enable register. ser_status_1 00_1006_0988 240/356 serial interface and dma status (read only, read clears). ser_int_mask_1 00_1006_0990 242/357 interrupt mask. dma_asic_addr_ser_1 00_1006_0998 94/166 asic mode address. ser_debug_status_1 00_1006_09a8 241/357 serial interface and dma status (read only, no side effects). ser_tx_byte_lo_1 00_1006_09c0 246/359 serial interface transmit byte count (low 16 bits). ser_tx_byte_hi_1 00_1006_09c8 246/359 serial interface transmit byte count (high 16 bits). ser_rx_byte_lo_1 00_1006_09d0 246/359 serial interface receive byte count (low 16 bits). ser_rx_byte_hi_1 00_1006_09d8 246/359 serial interface receive byte count (high 16 bits). ser_tx_underrun_1 00_1006_09e0 246/359 serial interface transmit underrun count. ser_rx_overflow_1 00_1006_09e8 246/359 serial interface receive overflow count. ser_rx_errors_1 00_1006_09f0 246/359 serial interface receive error packet count. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 474 section 16: reference document 1250_1125-um100-r ser_rx_badaddr_1 00_1006_09f8 246/359 serial interface receive address mismatch count. ser_rx_table0_1 00_1006_0a00 245/358 sequence table. ser_rx_table1_1 00_1006_0a08 245/358 sequence table. ser_rx_table2_1 00_1006_0a10 245/358 sequence table. ser_rx_table3_1 00_1006_0a18 245/358 sequence table. ser_rx_table4_1 00_1006_0a20 245/358 sequence table. ser_rx_table5_1 00_1006_0a28 245/358 sequence table. ser_rx_table6_1 00_1006_0a30 245/358 sequence table. ser_rx_table7_1 00_1006_0a38 245/358 sequence table. ser_rx_table8_1 00_1006_0a40 245/358 sequence table. ser_rx_table9_1 00_1006_0a48 245/358 sequence table. ser_rx_table10_1 00_1006_0a50 245/358 sequence table. ser_rx_table11_1 00_1006_0a58 245/358 sequence table. ser_rx_table12_1 00_1006_0a60 245/358 sequence table. ser_rx_table13_1 00_1006_0a68 245/358 sequence table. ser_rx_table14_1 00_1006_0a70 245/358 sequence table. ser_rx_table15_1 00_1006_0a78 245/358 sequence table. ser_tx_table0_1 00_1006_0b00 245/358 sequence table. ser_tx_table1_1 00_1006_0b08 245/358 sequence table. ser_tx_table2_1 00_1006_0b10 245/358 sequence table. ser_tx_table3_1 00_1006_0b18 245/358 sequence table. ser_tx_table4_1 00_1006_0b20 245/358 sequence table. ser_tx_table5_1 00_1006_0b28 245/358 sequence table. ser_tx_table6_1 00_1006_0b30 245/358 sequence table. ser_tx_table7_1 00_1006_0b38 245/358 sequence table. ser_tx_table8_1 00_1006_0b40 245/358 sequence table. ser_tx_table9_1 00_1006_0b48 245/358 sequence table. ser_tx_table10_1 00_1006_0b50 245/358 sequence table. ser_tx_table11_1 00_1006_0b58 245/358 sequence table. ser_tx_table12_1 00_1006_0b60 245/358 sequence table. ser_tx_table13_1 00_1006_0b68 245/358 sequence table. ser_tx_table14_1 00_1006_0b70 245/358 sequence table. ser_tx_table15_1 00_1006_0b78 245/358 sequence table. io_ext_cfg_0 00_1006_1000 251/374 cs0 interface configuration. io_ext_cfg_1 00_1006_1008 251/374 cs1 interface configuration. io_ext_cfg_2 00_1006_1010 251/374 cs2 interface configuration. io_ext_cfg_3 00_1006_1018 251/374 cs3 interface configuration. table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 475 io_ext_cfg_4 00_1006_1020 251/374 cs4 interface configuration. io_ext_cfg_5 00_1006_1028 251/374 cs5 interface configuration. io_ext_cfg_6 00_1006_1030 251/374 cs6 interface configuration. io_ext_cfg_7 00_1006_1038 251/374 cs7 interface configuration. io_ext_mult_size_0 00_1006_1100 252/374 cs0 region size in 64kb units. io_ext_mult_size_1 00_1006_1108 252/374 cs1 region size in 64kb units. io_ext_mult_size_2 00_1006_1110 252/374 cs2 region size in 64kb units. io_ext_mult_size_3 00_1006_1118 252/374 cs3 region size in 64kb units. io_ext_mult_size_4 00_1006_1120 252/374 cs4 region size in 64kb units. io_ext_mult_size_5 00_1006_1128 252/374 cs5 region size in 64kb units. io_ext_mult_size_6 00_1006_1130 252/374 cs6 region size in 64kb units. io_ext_mult_size_7 00_1006_1138 252/374 cs7 region size in 64kb units. io_ext_start_addr_0 00_1006_1200 253/375 cs0 region start address (put outside generic bus range to disable). io_ext_start_addr_1 00_1006_1208 253/375 cs1 region start address (put outside generic bus range to disable). io_ext_start_addr_2 00_1006_1210 253/375 cs2 region start address (put outside generic bus range to disable). io_ext_start_addr_3 00_1006_1218 253/375 cs3 region start address (put outside generic bus range to disable). io_ext_start_addr_4 00_1006_1220 253/375 cs4 region start address (put outside generic bus range to disable). io_ext_start_addr_5 00_1006_1228 253/375 cs5 region start address (put outside generic bus range to disable). io_ext_start_addr_6 00_1006_1230 253/375 cs6 region start address (put outside generic bus range to disable). io_ext_start_addr_7 00_1006_1238 253/375 cs7 region start address (put outside generic bus range to disable). io_drive_0 00_1006_1300 264/378 3.3v output drive strength and slew rate control registers. see section: ?drive strength control? on page 373 . io_drive_1 00_1006_1308 265/379 3.3v output drive strength and slew rate control register. io_drive_2 00_1006_1310 266/380 3.3v output drive strength and slew rate control register. io_drive_3 00_1006_1318 267/380 3.3v output drive strength and slew rate control register. io_ext_time_cfg0_0 00_1006_1600 254/375 cs0 timing parameter configuration 0. io_ext_time_cfg0_1 00_1006_1608 254/375 cs1 timing parameter configuration 0. io_ext_time_cfg0_2 00_1006_1610 254/375 cs2 timing parameter configuration 0. io_ext_time_cfg0_3 00_1006_1618 254/375 cs3 timing parameter configuration 0. io_ext_time_cfg0_4 00_1006_1620 254/375 cs4 timing parameter configuration 0. io_ext_time_cfg0_5 00_1006_1628 254/375 cs5 timing parameter configuration 0. io_ext_time_cfg0_6 00_1006_1630 254/375 cs6 timing parameter configuration 0. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 476 section 16: reference document 1250_1125-um100-r io_ext_time_cfg0_7 00_1006_1638 254/375 cs7 timing parameter configuration 0. io_ext_time_cfg1_0 00_1006_1700 255/376 cs0 timing parameter configuration 1. io_ext_time_cfg1_1 00_1006_1708 255/376 cs1 timing parameter configuration 1. io_ext_time_cfg1_2 00_1006_1710 255/376 cs2 timing parameter configuration 1. io_ext_time_cfg1_3 00_1006_1718 255/376 cs3 timing parameter configuration 1. io_ext_time_cfg1_4 00_1006_1720 255/376 cs4 timing parameter configuration 1. io_ext_time_cfg1_5 00_1006_1728 255/376 cs5 timing parameter configuration 1. io_ext_time_cfg1_6 00_1006_1730 255/376 cs6 timing parameter configuration 1. io_ext_time_cfg1_7 00_1006_1738 255/376 cs7 timing parameter configuration 1. io_interrupt_status 00_1006_1a00 256/376 interrupt status for generic bus sources (read only, read clears). io_interrupt_data0 00_1006_1a10 257/377 data latched on generic interrupt assertion (read only). io_interrupt_data1 00_1006_1a18 258/377 data latched on generic interrupt assertion (read only). io_interrupt_data2 00_1006_1a20 259/377 data latched on generic interrupt assertion (read only). io_interrupt_data3 00_1006_1a28 260/377 data latched on generic interrupt assertion (read only). io_interrupt_addr0 00_1006_1a30 261/378 address latched on generic interrupt assertion (read only). io_interrupt_addr1 00_1006_1a40 262/378 address latched on generic interrupt assertion (read only). io_interrupt_parity 00_1006_1a50 263/378 parity latched on generic interrupt assertion (read only). pcmcia_cfg 00_1006_1a60 273/393 pcicma controller configuration. pcmcia_status 00_1006_1a70 274/394 pcmcia controller status (read only, read clears interrupt). gpio_clr_edge 00_1006_1a80 276/398 write a 1 to clear the edge detector for that bit (write only). gpio_int_type 00_1006_1a88 277/398 select interrupt type for pairs of pins. gpio_input_invert 00_1006_1a90 279/398 set to invert the input. gpio_glitch 00_1006_1a98 280/399 set for 1ms glitch filter, clear for 60 ns. gpio_read 00_1006_1aa0 278/398 shows current value of signal after possible invert and glitch (read only). gpio_direction 00_1006_1aa8 281/399 gpio pin data direction. 1 for output, 0 for input. gpio_pin_clr 00_1006_1ab0 282/399 write 1 to set that bit to zero (write only). gpio_pin_set 00_1006_1ab8 283/399 write 1 to set that bit to one (write only). mac_tx_byte_0 00_1006_4000 167/288 rmon transmit byte counter. mac_collisions_0 00_1006_4008 167/288 rmon total collisions. mac_late_col_0 00_1006_4010 167/288 rmon late collisions. mac_ex_col_0 00_1006_4018 167/288 rmon excessive collisions. mac_fcs_error_0 00_1006_4020 167/288 rmon packets tx with bad fcs. mac_tx_abort_0 00_1006_4028 167/288 rmon transmit packets aborted. mac_tx_bad_0 00_1006_4038 167/288 rmon total of bad tx packets. table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 477 mac_tx_good_0 00_1006_4040 167/288 rmon total sucessfully transmitted packets. mac_tx_runt_0 00_1006_4048 167/288 rmon total runt packets transmitted. mac_tx_oversize_0 00_1006_4050 167/288 rmon total oversize packets transmitted. mac_rx_bytes_0 00_1006_4080 167/288 rmon total received bytes. mac_rx_mcast_0 00_1006_4088 167/288 rmon total received multicast packets. mac_rx_bcast_0 00_1006_4090 167/288 rmon total received broadcast packets. mac_rx_bad_0 00_1006_4098 167/288 rmon total received bad packets. mac_rx_good_0 00_1006_40a0 167/288 rmon total received good packets. mac_rx_runt_0 00_1006_40a8 167/288 rmon total runt packets received. mac_rx_oversize_0 00_1006_40b0 167/288 rmon total oversize packets received. mac_rx_fcs_error_0 00_1006_40b8 167/288 rmon total packets received with bad fcs. mac_rx_length_error_0 00_1006_40c0 167/288 rmon total packets received with length error. mac_rx_code_error_0 00_1006_40c8 167/288 rmon total packets received with code error. mac_rx_align_error_0 00_1006_40d0 167/288 rmon total packets received with align error. mac_cfg_0 00_1006_4100 176/301 ethernet interface configuration register. mac_thrsh_cfg_0 00_1006_4108 179/306 ethernet interface fifo threshold configuration register. mac_vlantag_0 00_1006_4110 181/309 vlan tag for insertion into packets on transmit mac_frame_cfg_0 00_1006_4118 180/307 ethernet interface mac frame configuration. mac_rx_fifo_ptrs_0 00_1006_4120 186/313 mac fifo pointers (debug, read only). mac_tx_fifo_ptrs_0 00_1006_4128 186/313 mac fifo pointers. (debug, read only.) mac_adfilter_cfg_0 00_1006_4200 192/315 mac receive address filter configuration register. mac_ethernet_addr_0 00_1006_4208 190/314 mac source ethernet address for insertion during transmission. mac_type_cfg_0 00_1006_4210 191/315 mac packet type table for receive packet comparisons. mac_admask0_0 00_1006_4218 188/314 address filter exact match mask register (periph_rev3). mac_admask1_0 00_1006_4220 188/314 address filter exact match mask register (periph_rev3). mac_hash0_0 00_1006_4240 189/314 address filter hash map. mac_hash1_0 00_1006_4248 189/314 address filter hash map. mac_hash2_0 00_1006_4250 189/314 address filter hash map. mac_hash3_0 00_1006_4258 189/314 address filter hash map. mac_hash4_0 00_1006_4260 189/314 address filter hash map. mac_hash5_0 00_1006_4268 189/314 address filter hash map. mac_hash6_0 00_1006_4270 189/314 address filter hash map. mac_hash7_0 00_1006_4278 189/314 address filter hash map. mac_addr0_0 00_1006_4280 187/313 address filter exact match. mac_addr1_0 00_1006_4288 187/313 address filter exact match. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 478 section 16: reference document 1250_1125-um100-r mac_addr2_0 00_1006_4290 187/313 address filter exact match. mac_addr3_0 00_1006_4298 187/313 address filter exact match. mac_addr4_0 00_1006_42a0 187/313 address filter exact match. mac_addr5_0 00_1006_42a8 187/313 address filter exact match. mac_addr6_0 00_1006_42b0 187/313 address filter exact match. mac_addr7_0 00_1006_42b8 187/313 address filter exact match. mac_chup0_0 00_1006_4300 193/317 receive dma channel select msb. mac_chup1_0 00_1006_4308 193/317 receive dma channel select msb. mac_chup2_0 00_1006_4310 193/317 receive dma channel select msb. mac_chup3_0 00_1006_4318 193/317 receive dma channel select msb. mac_chlo0_0 00_1006_4320 193/317 receive dma channel select lsb. mac_chlo1_0 00_1006_4328 193/317 receive dma channel select lsb. mac_chlo2_0 00_1006_4330 193/317 receive dma channel select lsb. mac_chlo3_0 00_1006_4338 193/317 receive dma channel select lsb. mac_enable_0 00_1006_4400 177/305 mac enable register. mac_status_0 00_1006_4408 182/309 mac status/error register (read only, read clears). mac_int_mask_0 00_1006_4410 185/313 mac interrupt mask register. dma_asic_addr_mac_0 00_1006_4418 94/166 asic mode base address. mac_txd_ctl_0 00_1006_4420 178/305 transmit dma control register. mac_mdio_0 00_1006_4428 194/317 mdio pin control register. mac_status1_0 00_1006_4430 183/312 mac status/error register (read only, read clears ch 1). mac_debug_status_0 00_1006_4448 184/312 mac status/error register (debug, read only, no side effects). dma_config0_mac_0_rx_ch_0 00_1006_4800 91/163 dma config 0 register. dma_config1_mac_0_rx_ch_0 00_1006_4808 92/164 dma config 1 register. dma_dscr_base_mac_0_rx_ch_0 00_1006_4810 93/166 dma descriptor base register. dma_dscr_cnt_0_rx_ch_0 00_1006_4818 95/166 dma descriptor count. dma_dscr_a_mac_0_rx_ch_0 00_1006_4820 96/167 dma current descriptor a. dma_dscr_b_mac_0_rx_ch_0 00_1006_4828 97/167 dma current descriptor b. dma_cur_dscr_addr_mac_0_rx_ ch_0 00_1006_4830 98/167 dma current descriptor address. dma_oodpktlost_mac_0_rx_ch_0 00_1006_4838 99/168 dma packet lost counter. (periph_rev3) dma__mac_0_rx_ch_1 00_1006_4900 rx channel 1 at rx channel 0 + 100. dma__mac_0_tx_ch_0 00_1006_4c00 tx channel 0 at rx channel 0 + 400. dma__mac_0_tx_ch_1 00_1006_4d00 tx channel 1 at rx channel 0 + 500. mac_1 00_1006_5000 mac 1 registers (+1000 from mac_0 registers). mac_2 00_1006_6000 mac 2 registers (+2000 from mac_0 registers). table 312: internal registers ordered by address (cont.) name address table/ page description user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r section 16: reference page 479 type 00 pci header 00_fe00_0000 - 00_fe00_00ff 127/236 configuration space bus=0,dev=0. type 01 pci header 00_fe00_0800 - 00_fe00_08ff 140/244 configuration space bus=0,dev=1. table 312: internal registers ordered by address (cont.) name address table/ page description bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page 480 section 16: reference document 1250_1125-um100-r user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r index page i i ndex numerics 16-bit gmii style packet fifo 299 a a comment on the term bank 103 a_cmd 22 , 78 a_l1ca 20 , 23 , 69 , 78 , 439 a_l2ca 23 , 26 , 77 , 90 , 93 , 164 , 206 , 212 , 224 , 230 , 242 , 439 accesses from the bcm1250 to the pci or hypertransport 214 accesses from the hypertransport to the bcm1250 216 accesses from the pci to the bcm1250 217 accessing the bcm1250 from an bcm1250 on a double hosted chain 212 accessing the bcm1250 from hypertransport devices 210 accessing the bcm1250 from pci devices 205 acknowledgement read access 369 acknowledgement write access 370 addr_trap_cfg 67 , 69 addr_trap_down 67 , 69 addr_trap_index 67 , 68 addr_trap_reg 53 , 67 , 68 addr_trap_reg_debug 68 addr_trap_up 67 , 68 address trapping 67 alias_mailbox_cpu 46 alias_mbox_set_cpu 46 asic mode 159 asynchronous mode 322 audience 3 b bank 103 bank address 117 baud rate 322 baud rate generators 322 BCM1125 1 , 3 , 4 , 120 , 136 , 190 , 194 , 196 , 264 , 292 , 425 , 430 bcm1250 block diagram 2 , 3 big endian system match bit lanes 203 match byte lanes 202 block 5 broadcom use only 6 bus error 53 , 184 , 211 , 249 bus error 77 , 136 , 137 bus error 18 , 18 , 25 , 53 , 64 , 66 , 111 , 112 , 215 , 235 , 240 , 241 , 364 , 369 , 374 bus error exceptions 18 bus width 365 bus_err_data 65 bus_err_status 17 , 18 , 53 , 65 bus_err_status_debug 65 bus_io_error 364 bus_l2_errors 17 , 66 bus_mem_io_errors 17 , 18 , 66 buserr-dpa 18 c cache block 5 cache error 17 cache error exceptions 17 cache line 5 cache management access 94 cacheability attribute 68 , 69 , 89 cacheerr-d 17 cacheerr-dpa 17 cacheerr-i 17 cas time check policy 122 cause 47 cf+ cards 390 channel select 109 checksum 178 checksum generation 178 chip select 110 choosing interleave parameters 120 clock ratios and clocking scheme 107 clock, reset and test 8 closed page policy 122 coldres_l 26 , 41 , 260 column address 117 comments on using the l2 as memory 93 compactflash 390 configuration header descriptions 236 configuration resistors 27 , 41 configuration space 194 connecting a pcmcia slot 384 cpu speculative execution 16 cpu to cpu communication 17 , 19 crc 178 , 180 , 269 crc generation 179 crc_def 179 , 185 crc32 (ethernet) 180 crc32c (iscsi) 180 crc-ccitt (hdlc) 180 ctcp_def 186 cts 322 , 323 , 324 d d_code 24 , 65 , 77 d_id 77 d_mod 25 , 77 d_rsp 77 data buffers 147 data mover operation 176 data phase 24 ddr fcram 123 ddr sdrams 123 debug_l 71 , 72 , 74 , 76 descriptors 147 destination address filtering 278 device mode 190 dint 47 , 48 , 50 direct connection of a memory only card 385 dll 128 , 138 dm_cur_dscr_addr 185 dm_debug_dscr_base 184 dm_dscr_base 177 , 184 dm_dscr_base_0 54 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page ii index document 1250_1125-um100-r dm_dscr_base_1 54 dm_dscr_base_2 54 dm_dscr_base_3 54 dm_dscr_count 185 dm_partial 186 dma asic mode 159 buffer 148 buffers 147 bytes before offset overwritten 155 coherence 155 completion interrupts 158 descriptor 149 descriptor chain 153 descriptor interrupts 158 descriptor ring 151 descriptors 147 , 151 , 154 , 156 disable 152 ethernet priority 156 l2 allocate 155 packet 149 pause 152 scatter/gather 155 watermarks 157 dma coherence and cache options 155 dma configuration 351 dma configurations 156 dma controllers 147 dma_asic_addr 159 , 160 , 166 dma_config0 148 , 156 , 157 , 163 dma_config1 152 , 156 , 159 , 164 , 285 dma_cur_daddr 167 dma_cur_dscr_a 167 dma_cur_dscr_addr 153 dma_cur_dscr_b 167 dma_dscr_base 166 dma_dscr_cnt 166 dma_oodpktlost 158 , 168 , 283 dram 103 dscr_a 149 , 149 , 154 , 160 , 169 , 170 dscr_b 149 , 149 , 154 , 169 , 170 duart 322 duart operation 323 duart_aux_ctrl 332 duart_clear_opr 324 , 335 duart_clk_sel 323 , 329 duart_cmd 323 , 328 duart_full_ctl 326 , 329 duart_imr 325 , 334 duart_imr_a 325 duart_imr_b 325 duart_in_port 324 , 330 duart_inport_chng 324 , 330 duart_inport_chng_a 331 duart_inport_chng_b 331 duart_inport_chng_debug 331 duart_isr 325 , 333 , 334 duart_isr_a 325 duart_isr_b 325 duart_mode_reg_1 323 , 324 , 326 , 327 duart_mode_reg_2 323 , 324 , 327 duart_opcr 322 , 324 , 331 , 340 , 342 duart_out_port 324 , 335 duart_rx_hold 326 , 329 duart_set_opr 324 , 335 duart_status 323 , 328 duart_tx_hold 323 , 330 e ecc 125 ecc diagnostic management accesses (ecc diag bits nonzero) 98 ecc error 64 , 66 , 89 , 91 , 94 , 96 , 97 , 104 , 125 endian policy as an optimization 204 little endian system 201 match bit lanes 203 match byte lanes 202 epc 17 errctl 17 , 18 ethernet 180 alignment error 276 , 291 code error 276 code error 291 collision 273 collisions 289 , 302 crc 269 crc error 276 crc error 274 , 291 dribble error 276 dribble error 291 excessive collision 273 excessive collisions 289 , 302 filter 278 flow control 284 frame format 268 inter-frame gap 308 interrupts 286 late collision 273 late collisions 289 , 302 length error 276 , 291 length error 303 mdc 287 mdio 287 overflow 273 , 277 oversize 290 oversize packet 276 oversize packets 291 , 303 packet type 282 pause frame 284 phy 271 prepended header 270 receive fifo 266 , 277 receive fifo 275 rmon statistics 289 runt 303 runt packet 276 runt packets 290 , 291 transmit fifo 266 , 272 underflow 273 , 277 underflow 302 underrun 290 ethernet and serial dma engines 157 ethernet mac 264 ethernet macs 264 user manual bcm1250/BCM1125/BCM1125h 10/21/02 broadcom corporation document 1250_1125-um100-r index page iii example startup code to clear the l2 cache 99 explicit descriptor interrupts 158 f feature control 219 fifo configuration 351 fixed cycle write access 368 flow control 284 flow control 294 flow control 152 , 271 watermark 157 g general timers 58 general_timer_cfg 60 general_timer_cnt 60 general_timer_init_cnt 60 generic bus address range 363 address space 362 burst mode 371 chip selects 362 data width 362 , 365 error conditions 374 parity 364 timing 365 generic bus errors 374 generic bus registers 375 gmii 264 , 267 gpio 397 gpio registers 399 gpio_clr_edge 54 , 55 , 398 , 399 gpio_direction 397 , 400 gpio_glitch 400 gpio_input_invert 397 , 398 , 399 gpio_int_type 54 , 55 , 398 , 399 gpio_pin_clr 397 , 400 gpio_pin_set 397 , 400 gpio_read 397 , 399 h hdlc 180 , 337 , 344 , 345 , 347 hint based policy 122 host mode 190 ht 190 hypertransport 190 access to pci 211 additional status register 255 bounce space 213 bridge command register 247 bridge control register 196 , 249 , 260 bridge primary (zbbus) status register 248 bridge secondary (ht) status register 248 bus number 234 command register 249 compat 195 compatibility space 197 configuration 194 configuration 234 configuration address 234 device number 234 diagnostic receive crc expected 255 diagnostic receive crc received 255 double-hosted chain 212 eoi 198 error control register 253 error status register 254 expansion space 194 function 234 generating interrupt messages 199 i/o space 195 interrupt acknowledgement 199 isochronous bar 252 isochronous bit 211 isochronous ignore mask 253 link configuration register 251 link control register 250 link frequency register 251 , 252 , 253 little endian system 201 match bit lanes 203 match byte lanes 202 memory mapped 194 odering rules 231 peer to peer 211 read restrictions 200 register 234 sri command register 252 sri data buffer allocation register 254 sri transmit buffer count max register 255 sri transmit control register 254 subtractive decode 195 target done 236 when not used 236 hypertransport configuration header 245 hypertransport expansion space 194 hypertransport fabric to pci bus 221 hypertransport resets 260 i i/o bridge 1 157 i/o bridge clocks 32 ifg 269 interface overview 265 interface to phy 271 interrupt_diag 50 , 52 interrupt_ldt 48 , 49 , 50 , 52 interrupt_ldt_clr 52 interrupt_ldt_set 48 , 52 interrupt_map 52 interrupt_mask 50 , 52 interrupt_source_status 50 , 52 interrupt_status 52 interrupt_trace 51 , 52 interrupts arbitrated 49 fixed 49 non-vectored 49 io_clk100 31 , 43 io_drive 379 io_ext_cfg 364 , 365 , 372 , 375 io_ext_mult_size 363 , 375 io_ext_start_addr 363 , 376 io_ext_time_cfg_1 365 io_ext_time_cfg0 365 , 373 , 376 io_ext_time_cfg1 377 io_int_status 53 io_interrupt_addr 379 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page iv index document 1250_1125-um100-r io_interrupt_addr0 364 io_interrupt_addr1 364 io_interrupt_data0 378 io_interrupt_data1 378 io_interrupt_data2 378 io_interrupt_data3 378 io_interrupt_parity 379 io_interrupt_status 18 , 364 , 374 , 377 io_multi_size 390 io_start_addr 390 ipv4 header checksum 283 iscsi 180 isocbar 212 isocignmask 212 j jtag 41 , 70 jtag and debug 422 l l1ca 23 l2 cache 89 l2 cache 89 l2_cache_disable 94 l2_ecc_tag 89 , 97 , 100 l2_misc_config 99 l2_misc_value 91 , 94 , 99 , 100 l2_read_tag 97 , 100 l2_way_enable 91 , 94 ldt 190 ldt_interrupt 55 ldt_interrupt_clear 50 ldt_pwrok 26 , 260 ldt_reset_l 26 , 57 , 260 line 5 line interface configuration 352 little endian system no swaps 201 m mac registers 302 mac_addr 314 mac_adfilter_cfg 171 , 172 , 279 , 282 , 283 , 285 , 293 , 316 mac_admask 315 mac_cfg 271 , 272 , 273 , 275 , 277 , 281 , 282 , 284 , 293 , 294 , 299 , 302 mac_chlo 281 , 294 , 299 , 318 mac_chup 281 , 294 , 299 , 318 mac_debug_status 313 mac_enable 301 , 306 mac_ethernet_addr 274 , 285 , 315 mac_frame_cfg 271 , 276 , 284 , 308 mac_hash 315 mac_int_mask 271 , 286 , 314 mac_mdio 287 , 294 , 318 mac_rx_fifo_ptrs 314 mac_status 157 , 271 , 273 , 277 , 285 , 286 , 310 mac_status_0 54 mac_status_1 54 mac_status_2 54 mac_status_debug 286 mac_status1 286 , 313 mac_status1_0 56 mac_status1_1 56 mac_status1_2 56 mac_thrsh_cfg 272 , 275 , 294 , 307 mac_txd_ctl 274 , 306 mac_type_cfg 316 mac_vlantag 152 , 164 , 274 , 285 , 310 macs 401 mailbox 48 , 49 mailbox_0 46 mailbox_1 46 mailbox_cpu 46 management interface to phy 287 mapping 109 mbox_clear 46 mbox_clr_cpu 46 mbox_set 46 mbox_set_cpu 46 mc_clock_cfg 127 , 138 mc_config 105 , 106 , 112 , 119 , 121 , 126 , 128 , 135 mc_cs_end 111 mc_cs_interleave 111 , 119 , 121 mc_cs_start 111 mc_csn_ba 121 mc_csn_col 121 mc_csn_row 121 mc_dramcmd 126 , 139 , 139 mc_drammode 123 , 124 , 126 , 139 mc_test_data 125 mc_test_ecc 107 , 125 mc_timing1 125 , 131 , 135 , 140 mc_timing2 125 memory barrier 107 memory clock 33 memory configurations 109 memory controller architecture 104 memory locked in the l2 cache 92 memory mapped devices 194 mesi 21 mii 264 , 267 n nmi 47 , 50 normal operation 89 not implemented 5 o open page policy 122 other documentation 4 overview of the zbbus protocol 20 p p_reset_l 57 p_rst_l 26 packet fifo 292 16-bit encoded mode 300 16-bit gmii style 299 8-bit encoded mode 296 8-bit eop flagged 298 8-bit gmii style 295 8-bit sop flagged 297 crc 294 , 299 flow control 294 packet fifo interface 264 packets dropped by the dma channel 283 page policy bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page v index document 1250_1125-um100-r cas time check 122 closed 122 hint based 122 open 122 pause frame 279 , 315 pause frame 305 pause frame 152 , 164 , 168 , 267 , 271 , 284 , 284 , 303 , 313 , 317 pci 190 , 401 match byte lanes 202 access to mailbox registers 207 adaptive extend register 243 , 244 adaptive retry 217 additional status and control register 242 arbiter 190 , 222 bar 205 bar0 map table entry 242 bus number 234 bus zero 191 bypass control register 244 cache line size 241 classrevset register 233 command register 240 compatibility space 197 configuration 194 configuration 234 configuration address 234 device mode 199 device number 234 devsel 206 endian policy (bar0) 206 errors 235 feature control 242 function 234 i/o space 195 idsel generation 235 inta control register 233 , 243 interrupt acknowledgement 199 latency timer 241 little endian system 201 match bit lanes 203 memory mapped 194 ordering rules 231 read 217 read host register 243 readline 217 readmultiple 217 register 234 status register 240 subsysset register 233 subtractive decode 195 , 196 , 199 timeout register 241 vendoridset 233 pci and hypertransport address range 192 pci bar2 46 pci bar3 46 pci bus and hypertransport fabric 190 pci bus to hypertransport fabric 219 pci configuration header 236 pci full access space 199 pci i/o space 195 pcmcia 384 attribute memory 386 status signals 386 pcmcia power control pins 401 pcmcia_cfg 386 , 387 , 390 , 393 , 394 pcmcia_status 395 pec 406 peer-to-peer accesses 219 perf_cnt 62 perf_cnt_cfg 61 performance monitoring features 134 performance of the pci and hypertransport interfaces 213 periph_rev3 6 , 81 , 91 , 94 , 99 , 103 , 117 , 123 , 126 , 138 , 140 , 152 , 154 , 158 , 163 , 164 , 168 , 171 , 172 , 177 , 178 , 185 , 186 , 187 , 270 , 279 , 282 , 283 , 285 , 301 , 305 , 308 , 310 , 313 , 315 , 317 , 372 , 425 , 448 , 449 , 478 , 479 phy 271 physical address 34 physical addresses 5 pll 31 , 41 , 43 preamble 269 prid 29 , 42 protocol engine and gmii/mii 267 protocol engine configuration 271 , 351 r r_exc 23 , 23 , 77 r_l2hit 23 , 77 r_shd 23 , 23 , 77 read only 5 receive path 277 receiver operation 275 reference 446 reserved 5 reset 26 reset_l 26 , 27 , 30 , 41 , 232 , 260 , 422 , 430 , 432 , 443 resetout_l 26 , 27 , 41 , 44 , 57 response phase 23 rings and chains 151 rmon 353 rmon counters 289 , 289 , 353 rmon statistical counters 265 row address 117 row, column and bank configuration 112 , 117 rts 322 , 323 , 324 s sb_softres 41 scd 41 , 89 sdram refresh 126 sdram timing 125 ser_addr_mask 348 , 359 ser_clk 340 ser_cmd 355 ser_dma_enable 357 ser_err_mask 346 ser_int_mask 358 ser_line_mode 354 ser_maxfrm_sz 345 , 348 , 357 ser_min_frm_sz 346 ser_minfrm_sz 345 , 356 ser_mode 341 , 343 , 344 , 345 , 346 , 348 , 354 ser_rx_rd_thres 356 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page vi index document 1250_1125-um100-r ser_rx_table 359 ser_status 157 , 341 , 343 , 346 , 349 , 357 ser_status_debug 358 ser_tx_rd_thres 346 , 356 ser_tx_table 359 ser_tx_wr_thres 346 , 356 ser_usr0_addr 359 serial configuration interface 404 serial interfaces 321 serial ports 401 sfd 269 signal description 7 smb_cmd 410 , 412 , 416 smb_control 413 , 416 smb_data 410 , 412 , 417 smb_freq 412 , 416 smb_pec 406 , 408 , 410 , 412 , 418 smb_start 408 , 410 , 412 , 418 , 419 smb_status 406 , 410 , 412 , 413 , 417 smb_xtra 412 , 417 smbus 404 smbus overview 404 smbus registers 416 southbridge 195 southbridge 195 southbridge 199 southonldt 196 special hypertransport space 199 sri command register 194 , 256 standard management mode accesses (both ecc diag address bits zero) 97 standard ram 92 subtractive decode 195 supported drams and dimms 123 synchronous interface configuration 351 synchronous serial loopback 352 synchronous serial protocol engine 344 system 41 system control and debug unit 41 system overview 9 system reset initialization of the hypertransport interface 256 system_cfg 41 , 42 , 43 , 321 , 373 system_manuf 43 system_reset 41 system_revision 41 , 42 system_scratch 42 , 45 t tcp 178 , 180 tcp checksum 283 terminology 5 the gpio pins 397 timer registers 59 timer special cases 58 timers 57 timing parameter guidelines 131 trace buffer 70 , 76 , 77 , 79 trace_cfg 75 , 76 , 79 , 84 , 85 , 86 trace_event 72 trace_read 76 trace_sequence 74 transaction id 21 transaction id 67 transmitter operation 272 transport protocol 404 trigger event 70 trigger sequence 73 u udp 178 udp checksum 283 undefined 5 unpredictable 5 using the l2 cache as memory 91 using the pci in device mode 232 v vga 195 vga display controller 196 viewing endian policy as an optimization 204 virtual address 5 vlan tag 269 vlan tag 270 , 274 w watchdog timers 57 watchdog_timer_cfg 59 watchdog_timer_cnt 59 watchdog_timer_init_cnt 59 write only 5 z zbbus monitoring 134 zbbus_cycle_count 58 , 61 zbbus_cycle_cp0 54 , 61 zbbus_cycle_cp1 54 , 61 bcm1250/BCM1125/BCM1125h user manual 10/21/02 broadcom corporation page vii index document 1250_1125-um100-r broadcom corporation 16215 alton parkway p.o. box 57013 irvine, california 92619-7013 phone: 949-450-8700 fax: 949-450-8710 broadcom ? corporation reserves the right to make changes without further notice to any products or data herein to improve reliability, f unction, or design. information furnished by broadcom corporation is believed to be accurate and reliable. however, broadcom corporation does not assume any liability arising out of the application or use of this information, nor the application or use of any prod uct or circuit described herein, neither does it convey any license under its patent rights nor the rights of others. bcm1250/BCM1125/BCM1125h user manual 10/21/02 document 1250_1125-um100-r |
Price & Availability of BCM1125
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |